Node's community is interesting — it's very greenfield. They have had the opportunity to built everything from the ground up, together, and take a fresh approach to all problems other languages have faced. Unfortunately, that led to a lot of wild-west style ground-staking, and the tremendously large number of silly dependencies (like mkdir_p) floating around.

They also had to figure out the "we need a foundation to own/protect the IP of the platform", something that Python's had for a very long time withe the PSF.

Generally, I have little respect for most Node developers. There are a lot of great ones out there, and it's the right tool for a lot of jobs. However, most Node developers generally seem to be very new programmers that really have no idea what they're doing, and often have a big chip on their shoulder to go along with it.

Hope that wasn't too negative!

I love emulsions. I don't use them often, as they are incredibly inconvenient, but I do shoot them from time to time, and develop b/w myself at home. To me, it's very magic, and far more impressive to me than any digital camera/photo will ever be.

I just cannot believe that we can capture perfect snapshots of light and burn them onto film using only chemicals. That absolutely blows my mind. :)

Vinyl used to be required, now it's a luxury, because it's optional. Same with film.

GitHub used to have comments enabled on their blog. I used to be a very active GitHub community member. One day, they posted that emojis were now supported, everywhere.

Excited, to be the first comment, I entered the first thing I could think of: ✨🍰✨

I didn't like it, and it seemed overhyped.

I've used Docker for Mac now, as well as the Heroku Docker beta registry. This makes the experience of using Docker much pleasant. So much so, that I think I like it — for certain things.

I do still think it's generally overhyped though. Not really sure why your average so developer is excited about it. But, a useful tool, certainly.

About 9 months into it. I didn't do anything for it to happen—it just happened on its own. I just woke up one day, and sort of "knew" Python—after struggling with basic things for months and giving up.

I had to experiment a lot with different things of course, but that's what makes Python so great, in my opinion—the ease of experimentation with the interpreter and the object model.

This is the most useful part of the Python documentation, in my opinion: docs.python.org/3/reference/datamodel.html

I have the same problem, severely. Honestly, if I can't finish something in a single setting, it's never going to get done. So, most of the things I'm most proud of, like Requests, were the result of staying up far too late at night and just getting it done, at least the first version. Then, the next day, make it a little better. Rinse and repeat.

That's what works for me.

💫✨🍰✨💫

Thanks so much! :)

The push was pretty easy to pick up — just takes a lot of practice, like any other instrument. After a while, it becomes second nature.

I don't consider myself to be talented at the Push at all. I'm just very grateful that I can use it to preform music that I cannot on a traditional keyboard.

Thanks for listening to the album! That means a lot to me :)

The quick brown fox jumps over the lazy dog

yes.

It's very fun to do exactly what you said.

But, I think the main fun part for me is making something beautiful. Like, really putting the absurd amount of polish on every aspect of something (from API consideration, to documentation, to file layout, to fun unnecessary humor in comments) is immensely rewarding for me. I strive, in projects like that, to just set the bar for quality in all aspects.

The only project that actively still does that is Requests, really. I think it did a good job.

Always room for improvement though!

pass would be 🔜

I love really well designed things. Python is really well designed.

I'm not familiar with this API, actually! Looks interesting, will read up on it soon.

But, knowing how many standard library APIs are, it wouldn't surprise me if a third-party wrapper wouldn't be beneficial for many.

• Everyone using Python 3 (or 4, by then).
• PyPy being far more prevalent, but not the default.
• More serious datascience users. Much more.
• Ideally, the standard library will start to shrink in size.
• PyCon, if it is to somehow remain a single gathering as it is today, will reach the size of 8000+ attendees.

I feel like I haven't gotten any better at Python in about 2.5 years. I'm not sure if that's true or not, but it feels that way. It feels like the culture around the code has changed a bit, as least in my circles, which is primarily web development. I build and maintain rock-solid, stable software. I have all the tools I need to do so. There's nothing new or exciting for me to play with to accomplish any of these tasks anymore.

Docker is the only exception that rule that I know of. And, Kafka, if I ever get around to figuring it out :)

As to improving, I just always had a bunch of ideas, and I was always working on them. Working on one idea would teach me something, which would lead me to the next idea, etc etc.

So, build things! You'll keep getting better and better at it.

It's not an academic exercise. It's like carpentry. You get better primarily by.... doing it.

I call myself Kenneth Reitz because that is the name my parents told me I have when I was born. My birth certificate and subsequent documents appears to confirm this. I also like the name :P

If Requests were an animal, it would be a mantis shrimp — for many reasons, especially their eyes.

The Pythonista crossed the road while waiting for a GIL context switch to randomly occur.

I don't really consider myself to be a DevOps engineer, but my best guess is this:

• Normal stuff for regular engineer.
• Additionally, embed yourself in a community of an ops tool you love (e.g. Ansible).

Honestly, I haven't been doing much recreational coding for a while now. I have many hobbies (all the main ones you mentioned), and I seem to rotate them as my interests ebb and flow.

Sometimes, I'm interested in photography and software development, and I do both every day. Sometimes, I'm interested in making music, and software development, and I don't touch my camera for months. At the moment, I'm interested mostly in photography and making music, and haven't touched software development in a while.

I'll switch it up soon — I think :)

English has a tendency to invoke excitement within me, when used in specific ways :)

Seriously though, no other programming language really interests me much at all. If I did lower-level programming, I'd be pretty excited about Rust — but I don't. Python's pretty great for my needs.

I hope it stays that way.

I have not used Ansible, actually. I only have one or two servers that I administer, thanks to Heroku, and ideally it would be zero.

I'm sure that will change one day :)

This is a complicated question with a complicated answer. I'll do my best to answer it as simply as possible :)

Basically, I work on a team that has quarterly priorities. External requests can come from external sources (e.g. other teams, sometimes teams of effectively PMs), and we can schedule in advance accordingly. Having things planned out quarterly allows us to communicate to those other groups our available bandwidth to take on new projects from outside the team.

This has change a lot in the 4.5 years that I've worked at Heroku. I think we've struck a great system.

Hope that helps!

The first time I ever saw Python was when I was a young kid, in elementary or middle school, installing random Linux distributions on my machine that I had the CD for. One of them had "Loading Python" or something similar during the bootloader.

For actually writing Python, I started that in 2007. I had done a lot of really amateur toy programming as a kid: C, Pascal, etc. Python was the first language I picked up and learned how to do things beyond a loop and a function.

I have the first piece of Python I attempted to write. Enjoy: https://gist.github.com/kennethreitz/241997

• Wake up whenever.
• Answer support tickets.
• Go for a walk to get lunch and coffee downtown.
• Proceed to work on some of the tasks that I have planned for the week (like improve some component of the Python build process, submit a conference talk, or something like that).
• Engage with community intermittently.
• Engage with company intermittently.
• Email, email, email (intermittently).
• Answer support tickets.

That's your run-of-the-mill day :)

I recommend everyone use Sublime Text. It's really the best editor available for the type of development that I do.

Some people do prefer IDEs, which can be really fantastic tools at times. If so, I highly recommend PyCharm IDE. I have done a significant amount of work with it in the past (including a lot of Requests development!)

I prefer a work atmosphere where I have tons of personal freedom—for me, that means that I work from home, and I don't have a daily standup. Working in an office every day, or even having a remote call at the same time every day with the team really wears me down and gives me a lot of stress. Offices are okay, but I'm just much more efficient (and, more importantly, happy) at home.

My only advice to people wanting to switch from one profession to programming is this: don't try to be a programmer for any reason other than you love it.

In many of my talks, you'll hear me say that the API is the most important part of a codebase. That is true, because it's the most primary part of the UX of the code itself.

When it comes to the project as a whole though, beyond just the codebase, there are many other places were UX opportunities are surfaced, and one of the biggest ones is documentation.

Documentation is incredibly important for doing a handful of things:

• Communicating with your userbase the expectations and tone of the project
• Explaining how to use it (e.g. a quickstart) in simple terms
• Explaining how to get really deep into it (e.g. an advanced section)
• API reference

As a bonus, it also helps you, as a developer, explain your crazy technical ideas in layman's terms. Sometimes, this may prove to be a difficult task, which may lead you to re-visit the code you are attempting to document.

All of the above things make writing documentation a very important part of writing any library that will have a userbase (which is ideally, all of them), in my opinion. There's tons of motivation there. Why are you writing the code in the first place?

Kenneth Reitz's Tips for Releasing Open Source

• Communicate clearly and concisely. Have a great, useful README.
• Don't waste anyone's time.
• Why should they use your project? It should be immediately obvious.
• How do they use your project? It should be immediately obvious.
• How do they install your project? It should be immediately obvious.
• Be really open about the development, if you're on social media (e.g. Twitter).
• You have to be excited about what you're building, for others to be excited about it.

SETUP.EXE

I use a 5K iMac for almost everything. I love having a single screen and a single computer for almost everything I do. Over the years, I've had a ton of laptops that I used 100% of the time. Nowadays, I'm more sedentary, and enjoy being fastened to my desk. Of course, I have the Macbooks I need to work from anywhere, but I rarely do.

Gadgets? Oh, I have many. I'll just name a few random ones.

• Tivoli Audio Model One: a real analog AM/FM radio that sits on my desk.
• Leica Q: my camera, which I take with me almost everywhere I go.
• Ricoh GR: secondary camera, fits in my pockets, looks like a toy. Is not a toy.
• Pilot Vanishing Point: an absolutely fantastically designed fountain pen.
• Microfiber Cloth: most recent addition. I use it constantly, and keep it in my pocket.
• Synths: Moog Sub37, Arturia MicroBrute, Korg VolcaKeys, Roland TR-8. I used to have many more synths. I have downsized.
• Ableton Push 2: I can't play keyboards (I don't know the scales). I can with this. Well.
• Portable Music Studio: Korg Electribe 2. Google it. It's crazy.
• Dymo Label Maker: shockingly useful. I use it constantly (including to make the Requests stickers for PyCon this year!). $10.
• Tektronix 2213A Analog Oscilloscope: a very useful feedback tool for anything electronic (e.g. audio signals).

Thanks for the great question! ✨🍰✨