I built a thing for Buttondown that lets you embed an iFrame to handle subscriptions really nicely:
Changelog entry coming shortly, but pretty pumped about this — embeddable subscription widgets! pic.twitter.com/uf2UjQILZt— Buttondown (@buttondownemail) August 6, 2017
This thing necessitated a change in the UI: The current share page was pretty gross (below), and this was going to make it grosser:
I’ve been programming for the better part of a decade, and I’ve been programming in Python for the better part of that better part.
As loathe as I am to assume the mantel of “X Engineer”, if I were to describe my career in relation to any technology it would be “Python Engineer”.
It is the language I feel most comfortable with; it is the language I reach to first when starting a new project; it is the language I write daily. It is as frictionless as English.
And yet I still find myself losing hours to things I thought I had mastered.
I had some misgivings with the post and the ideas it espoused — namely, that “bloat is bad” is a reductionist truism — but still admired the approach Sandofsky took and the clear tradeoffs and sacrifices he discussed.
First, some background and context, because I’m a super persnickety podcast listener:
- I think podcasts, like anything else, need to be interesting and timeless. If an episode is useless or pointless to listen to three months after its publication, then its a bad episode; if that describes most episodes, then it’s a bad podcast for me. 1
- I don’t like most politics or tech news podcasts, mostly because they end up guilty of the above.
- I don’t like comedy podcasts, much to my chagrin. 2
- In my experience, most interview-style podcasts are more marketing/PR than actual information. Obviously that’s a broad brush (and a couple of the podcasts on this list are interview podcasts!), but in general I feel like the ROI on interviews are low.
- This list is constantly evolving. It was last edited in August of 2017. (And I’m always looking for new things to listen to!)
I’ve been spending a lot of time working on Buttondown lately and, as you might expect for a newsletter app, lots of this work revolves around dealing with email addresses.
In an effort to save myself and others some time, I’m trying to collate a list of usefully distinct and weird invalid and valid addresses for test harnesses and such. Below is what I have so far: it’s not a complete set, but it’s comprehensive enough to handle most of the weirdnesses out there.
I want to do an earnest, thorough analysis of Buttondown’s launch at some point in the future: what the traffic was like, conversion rates, et cetera. (Truth be told, I haven’t even looked at those numbers yet — there were a bunch of visitors, there were a bunch of signups, and that’s pretty much all I know because I’ve been so in the weeds with work the past week and a half.)
Sometimes there are things that are so good it actively makes me angry, because it presents a version of the form that seems unimpeachable.
Money Things is like that — it is such a good newsletter, so dense and interesting and funny that it makes me mad, because having to read, like, Hot Pod or Pro Rata or other industry newsletters after it is just an exercise in dwindling returns.
Lincoln in the Bardo was like that — it was such an interesting and beautiful and novel piece of work that it retroactively invalidated so much of what I had consumed beforehand. It was my first audiobook, too, and it basically ruined audiobooks for me, because how do you top that?
And now, this. This product page for Transmit 5.
Jakob Nielsen wrote in 1993 about the three important demarcations in response time. This is a terrific article that I come back to every year or so and see how my interpretation of it has evolved, like reading an old book to see how your perspective of the narrative changes over time.
0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
10 seconds is about the limit for keeping the user’s attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.
Those three benchmarks were set in 1968; Nielsen was commenting on how remarkable it was that 25 years later they still held mostly true.
Chris Eidhof tweeted a good thing:
The word 'simply' can often create a huge distance between the author and the reader (when the reader doesn't understand straight away).— Chris Eidhof (@chriseidhof) July 13, 2017
One of the replies to the tweet was also very good:
I’ve found that I’m personally tempted to use the words “simply” or “basically” when I don’t know how to actually explain something 😅— JP Simard (@simjp) July 13, 2017
This reminds me of a lesson learned back when I was an English major 1.
I’ve seen three different iterations of “code review culture”, and all of them have been positive with minor tweaks and changes. What follows is a general list of observations and advice:
“Finding and preventing bugs” is a secondary goal of code reviews, not a primary one.
You shouldn’t be relying on your code reviewers to find bugs; it’s nice to have an extra set of eyes who can point them out, but it’s your job as the implementer and tester to ensure correctness.