![](/style/images/good.png)
![](/style/images/bad.png)
Notes from PyTexas 2019
source link: https://mtlynch.io/retrospectives/pytexas-2019-notes/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
![neoserver,ios ssh client](/neoserver-download.png)
Overview šļø
This past weekend, PyTexas invited me to speak at their annual conference in Austin, Texas.
It was a fun trip, and I learned a lot. It was also expensive, both financially and in terms of time. Iām taking these notes partly to share what I learned and partly to help me decide whether the benefits I get from attending conferences outweigh the costs.
Favorite Talks šļø
Intentional Deployment: Best Practices for Feature Flag Management šļø
Speaker: Caitlin Rubin from Optimizely
Feature flags allow a software team to change an applicationās behavior at runtime rather than pushing an entirely new deployment. For substantial changes, you often want to do a progressive rollout, enabling it for 1% of users, then 5%, then 25%, just so that you can limit the damage if the change causes things to blow up in production. Teams frequently achieve this slow rollout with feature flags.
Feature flags suffer from the tragedy of the commons problem. Itās easy for any individual developer to add a flag for their new feature, but if everyone constantly puts in new feature flags, the application accrues so many different execution paths that it becomes difficult to reason about the programās behavior. Further, once the team enables a feature globally, the developer has little incentive to do the grungy work of removing the branching logic and eliminating the flag.
This talk succinctly explained feature flags, why they can cause problems, and shared concrete steps for preventing those issues. In particular, I liked Caitlinās suggestion of a āWIP limitā - a work in progress limit. If your team sets a WIP limit of two, then only two feature flags can exist at a given time. This encourages developers to be thoughtful about when to use feature flags and ensures that developers remove the flags when the application no longer requires the branching feature logic.
Other things I liked:
- Slide deck was clean, never overwhelming the audience with text
- Slides advanced or updated every few seconds to keep things moving
- Caitlin telegraphed comfort on stage, spoke clearly and calmly
- Good mix of humor sprinkled throughout the presentation
Free yourself from your ORM with mypy! šļø
Speaker: Thomas Stephens from uStudio
Iāve always had an aversion to object-relational mapping (ORM) frameworks. They allow developers to move application objects in and out of data stores without having to implement a lot of serialization and deserialization logic by hand. Thomas articulated the problem Iāve always had with ORM systems but could never put into words: they bind your object model to your ORM framework.
Iāve also seen mypy and understood the appeal, but I tried it about a year ago and had a hard time getting it to work on my projects (most of which are Python 2.7), so I just gave up. If you havenāt seen it, itās a static type checker for Python. It reads PEP 484 type hints in your code and tells you when youāre violating them.
This talk provided a gentle introduction to mypy and highlighted a far-reaching benefit of using it. Namely, implementing your own data serialization and deserialization without too much hassle and leaning. Thomas demonstrated how you can lean on the type checker heavily to prevent common serialization errors.
Other things I liked:
- Clear articulation of the problem heās trying to solve
- Simple live-coding that was easy to follow
- Code was elegant and clear
When Booleans Are Not Enoughā¦ State Machines? šļø
Speaker: Harrington Joseph from Netflix
Applications often use booleans to track an objectās state. Because Harrington is with Netflix, he used the example of a video player, which highlighted the issue well. A video can either be playing, paused, or stopped. A naive approach would track this with booleans like is_playing
and is_paused
.
Managing state like this imposes a heavy burden on the developer because now they have to do a lot of work to deduce state. Inferring a āstoppedā state requires checking is_playing == False and is_paused == False
, which is convoluted. It also puts a lot of work on the developer to check illegal state transitions. For example, you canāt pause a video thatās already stopped, so enforcing that restriction clutters your code.
Harrington demonstrated how the pytransitions library elegantly solves that problem. It allows you to define your applicationās state transitions with a simple list of states ā then the library manages all the transitions for you. You can check which state youāre in, and the library raises an exception on any illegal state transition; you donāt have to write any code to check it manually.
Other things I liked:
- Beautiful slides
- The dark theme worked well
- The full-screen code snippets with syntax highlighting made it easy to read
- Great diagrams of state machines that were easy to understand
- Clear code examples
- Elided out code that wasnāt relevant to his core point, making everything easy to think about
Other notable takeaways šļø
There are code review tools for prose šļø
This had nothing to do with Python but was a valuable gem I picked up serendipitously by talking to another conference attendee.
One idea Iāve had for a future project is to build something like Reviewable, but for prose content instead of code. Iāve searched for tools like that but found only heavyweight tools geared toward large publishers (e.g., tools for newspapers, optimized for complicated workflows with many approvers). When I talked to Caitlin Rubin, she mentioned to me that she knew of a tool like that called Penflip.
The first day I tried visiting Penflip, I got a 502 gateway error even after many retries. The next day, the page loaded, but everything was extremely slow and ultimately led to unrecoverable server errors. So, it seems like it might not be an active product anymore.
Still, having one product name gave me a toehold to search for others. Apparently, thereās a whole mess of ācode review, but for contentā products out there that have failed:
- Draft: One of the few still-functional editing apps but doesnāt seem to support reviews well.
- Editorially: This was a free tool that people reputedly loved, but it shut down in 2014. I found many articles mourning its closure.
- Typewrite: Site is still up, but functionality is broken to the point that I canāt even sign up. Last Twitter post was in 2014, so I think itās dead.
- Poetica: Iāve seen this mentioned, but itās now dead. Didnāt seem especially popular.
The Zen of Python šļø
Several speakers mentioned The Zen of Python, a famous list of guiding principles for Python. I had never seen this list before, but theyāre good to know. They also appear in any Python interpreter if you type import this
.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
PyCon is a big deal šļø
Several people spoke glowingly of PyCon. PyTexas is a small, regional conference, but PyCon is national ā the big leagues. It sounds like the quality of presentations is high and there are more helpful people to meet. I had been relying on PaperCall to show me upcoming conferences, but I donāt think PyCon used it, so I missed the submission deadline. I need to add it to my calendar for next year.
What made presentations effective šļø
- Speaker comfort
- The talks that were the best were ones where the speaker felt comfortable and took their time.
- The best example of this was Adrienne Loweās keynote, āThe Zen of Python Teams."
- Personalization
- I found talks more engaging when the speaker was part of the story. What problem were you trying to solve? What were the challenges you faced? What did you learn? Answering these questions was far more engaging than just a dry summary of ādid you know tool X exists to solve problem Y?ā
What weakened presentations šļø
- Mic issues
- Itās unfortunate that one of the most common things to take me out of presentations was something so basic and boring as audio quality.
- The conference used the Tony Robbins-style over the ear mic, which many speakers had trouble positioning correctly, so audio would often drift in and out.
- Other speakers chose a handheld mic but had trouble holding it close enough to their mouth and speaking loudly enough for the mic to pick it up.
- Slide lethargy
- The best presenters kept their slides moving briskly. They either advanced a slide or made a new bullet appear at least once every 30 seconds. I remember a feeling of āstucknessā when presenters kept the same slide up without changing anything for 60 seconds or more.
- Script-reading
- Part of the fun of attending a live conference is that you, as the attendee, are part of the talk. The speaker is responding to your energy and adapting their presentation accordingly. When the speaker has long sections that theyāre reading verbatim from a script (or worse, when the entire presentation is a static script), you lose the fun of a live presentation.
- Animated gifs
- I found these distracting, especially if they sat on the screen looping for more than a few seconds.
- I often felt the cheap joke undermined the speakerās point.
- āThis is an old slide.ā
- A few presentations included information that was a year or two out of date because they were recycled from previous conferences. The speaker excused it by saying the slide was old, but it always made me feel disappointed that the speaker didnāt care enough about their talk to do a run-through beforehand to catch these issues.
Critiquing my own talk šļø
Speaker: Michael Lynch (me)
-
What went well
- Preparedness: I did 5-8 run-throughs in the weeks leading up to the talk, so I felt comfortable with the material.
- Slide pacing: Reviewing the video, it feels like Iām avoiding slide lethargy and moving the presentation forward at a good pace.
- My dig at Java (see 16:15) got a good laugh.
-
What needs improvement
- Slow down: I was talking way too fast. I forgot to keep a timer up, so I was in kind of a rushed panic to finish on time. My rehearsals were running about 27 minutes, but at the real event, I went so fast that I only used 22 minutes of my half-hour slot.
- Look up more: I spent too much time looking down at my screen to read the content instead of engaging the audience.
- āMagic numbers are fine in test codeā (at 19:58)
- This line needed more justification. Fortunately, someone asked about this in the Q & A, so I was able to cover it, but it should have been part of the presentation proper.
Other thoughts šļø
Attending as a speaker is more valuable than attending as a regular guest šļø
In considering whether to attend more conferences, Iāve debated whether I should go to some as an attendee rather than as a speaker. I feel like thereās about an order of magnitude more value in attending as a speaker.
People are more interested in talking to you as a speaker. This is true even before youāve given your talk because thereās a feeling of, āOh, well you must be good at something.ā And then after your talk, people who want to meet you have an easy topic to discuss with you because they know at least one thing youāre passionate about.
I also found that speakers made a more lasting impression on me than other attendees. I had conversations with lots of interesting people, but the ones that stick with me days later are the ones who gave a talk.
I should have asked for something šļø
Every speaker effectively gets a free ācall to actionā in their presentation. For most speakers, itās an invitation to apply to their company or to use their product. Iām not hiring, and Iām between projects, so a call to action didnāt occur to me.
About an hour after my talk, I thought, āOh, I should have asked businesses to send me their pain points!ā I suspect that many PyTexas attendees have some part of their day jobs where they think, āI hate doing this. Why isnāt there a managed service that handles this for us?ā A lot of those problems go unsolved because itās hard for product-builders to connect with small businesses that have unmet needs. PyTexas might have been a good place to just say, āHey, come talk to me, and maybe Iāll build that service for you.ā
Single-track conferences have a different vibe šļø
This was the first conference I attended that was single-track. By this, I mean that only one presentation was happening at any given time, so attendees never had to decide which talks to attend because there was only ever one choice.
The single track was positive in that everyone saw the same talks, so you could discuss any presentation with anyone else, and they probably saw it. As a speaker, itās also nice to have 100% of the audience see your talk.
The downside is that single-track events lack the shuffling that multi-track conferences create naturally. In a multi-track conference, most people move to a different room after each talk and end up meeting new people. At PyTexas, most people stuck to a single table the entire day, so there was less mingling than Iāve seen at other conferences.
Costs šļø
I ended up spending more to attend this conference than I expected:
Expense Amount
Airfare $699.96
Airbnb (2 nights) $253.26
Airport parking $89.79
Uber rides $81.93
Gas $33.01
Food $26.29
PyTexas ticket $85 (free through PyTexas grant)
Total $1,184.24
Beyond the monetary cost, it was expensive in terms of time. Itās a two-day conference, but it wiped me out for about five days. I lost roughly a day in transit each way, and then it took me about a day to catch up on non-work errands that Iād missed while I was away. Outside that, I spent 20-30 hours preparing my slide deck and rehearsing it.
Conclusion: Keep attending, but strategically šļø
At the beginning of the year, I set a goal to speak at three conferences in 2019. PyTexas was conference #2, so I think one more for the year will be a good amount.
The benefits for me are meeting new people, hearing about tools and techniques that I otherwise wouldnāt be exposed to, and getting practice public speaking. One of the biggest takeaways was learning about Penflip, which was wholly unexpected but could save me tons of time and money in avoiding their mistakes.
Recommend
-
4
Following on from last yearās notes on books read in 2018, here are my notes for 2019. Again, these are not reviews, more notes on things I found interesting in th...
-
12
Week notesotsukare Thoughts after a day of workWeek notes - 2019 w51 - worklog - Last week Ven 20 dƩcem...
-
7
Hello, someone is here?otsukare Thoughts after a day of work Webcompat bugs Brian Birtles has a strange issue that...
-
11
The Weak Notesotsukare Thoughts after a day of workA week with a bad cold makes it more difficult to write week notes. So here my weak notes. Everything seems heavier to type, to push....
-
4
Week notesotsukare Thoughts after a day of workWeek notes - 2019 w48 - worklog Sam 30 novembre 2019by
-
4
Week Notes? Week Notes. I'm not sure I will be able to commit to this. But they have a bit of revival around my blogging reading echo chamber. Per revival, I mean I see them again. The
-
2
Notes from the Internet Health Report 2019 21 September 2019 ć» category: write-ups ...
-
11
Visual Studio 2019 version 16.8 Release Notes 12/08/2020
-
16
Visual Studio 2019 for Mac version 8.8 Release Notes 12/15/2020...
-
3
Quick notes for Mozilla Whistler All Hands 2019otsukare Thoughts after a day of workWhistler 2019 Quick Notes (taken as it comes, without a specific logic, just thoughts here an...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK