08 February 2016

Explaining your solution is always harder than the original problem

When you're trying to solve a technical problem (writing code, analyzing data, designing systems), it's easy to decide that your work is done as soon as you verify that your results are valid (with tests, example cases, etc). But in practice, I find that being "done" only marks the beginning of the most important and most challenging phase: successfully explaining your solution to someone else.

While I'm in the zone, I can too easily convince myself that I've got a problem completely figured out. Later, I'll be explaining my ideas to someone else (in a meeting, document, code review, etc) and surprise myself by tripping over words, using bad analogies, and going into extraneous detail. I realize that I'm not making sense. The reality is that I can't explain my thoughts. My solution may as well not exist.

In my experience, the only way to make the act of explaining easier is to simplify the concept you're trying to explain. Simplifying is a skill that takes practice. You have to ask yourself, why can't a solution that's described in 500 words (or lines of code) be reduced to 250 or 100? You need to identify concrete reasons for why it can't be any shorter (e.g., nuance, abstraction, edge cases). You must ruthlessly cut things down as much as possible.

There are a few habits I've tried to cultivate to get better at simplifying:

  1. When I write (code and words), I spend time optimizing for the reader. I try to present the important parts before the details.
  2. When I get some new code working, I assume that I've only made it to the half-way point. I expect that refactoring and code review will take half of the overall time.
  3. Similarly, when I'm writing (design documents, emails, etc), I expect that editing will require at least 50% of my time.
  4. When someone else tells me their solution to a problem, I (annoyingly) say "let me repeat that back to you" and attempt to explain what they told me in different terms. It's amazing how often I'm wrong.

People too often assume that it takes more effort to have more (more words, more code, more features, etc). Adding more is actually the easy part. The hard part is having less in the end. The hard part is editing, reducing, refactoring, boiling it down.

18 January 2016

Website of mine from 2009 went down. Source code not in the usual places. Uh-oh.

Found it in an automated backup! Phew~ Thanks Arq!

16 January 2016

Why I don't use functional programming languages

There was some interesting discussion (thread1, thread2) following my answer to the question of "How do you choose the programming language for a project?" My preferred languages are Python, Go, C++, C#, JavaScript, C, Java, TypeScript, and Swift. Functional languages (Lisp, Haskell, OCaml, etc) are conspicuously omitted from my list. Why?

What if the programmers who prefer functional languages are essentially "left-handed"? Some product of nature and nurture leads most programmers in the world to be "right-handed", preferring imperative programming languages over functional ones. Some especially gifted people are "ambidextrous" and work well with both types depending on the situation.

What if the choice between imperative and functional languages is purely subjective? They are two different perspectives on accomplishing the same thing. There are advantages and disadvantages to both. Neither approach is empirically better. One is much more common for unclear reasons. Programmers of either preference can't quite understand the appeal of the other side.

I'll leave it at that. And for the record: I'm also right-handed.

12 January 2016

How do you choose the programming language for a project?

Here's my take as a decision tree. Which leaves/roots would you change? Why?

30 December 2015

Holiday project this year

I've been making a game this holiday break. The big surprises so far: 1) Unity is an incredible tool (see screenshot below), 2) I like C# more than Java. The game simulates the physics of orbits. I'll report back when I've made something playable!

20 December 2015

I enjoyed this post about one team's transition from Scala to Go. I think it's about how discouraging cleverness is important in programming languages and codebases. I don't think this article is about Go. The point here is the Scala language (and a popular library) made it possible for the code to be opaque to his own teammates (who were also Scala programmers!). Choosing to use Go going forward is one possible conclusion. If the article said that they chose to use vanilla Java 8 instead, I think the takeaway would be the same.

(From this discussion)

16 December 2015

If I could change one thing: I'd write code so it's easier to delete features than to add them.

06 December 2015

Is it really open source? Or is it just content marketing for developers? Too few projects pass the test.

05 December 2015

It's amazing to me that Microsoft has been able to change so much culturally over the past few years: "Microsoft Edge's JavaScript engine to go open-source".

04 December 2015

Interesting post by Brett Cannon: "If I were designing Python's import from scratch"

25 November 2015

Fun sailing game you can play in your browser. You need a keyboard. Arrow keys to steer, Z and X to trim the sail.

15 November 2015

Huge list of projects that build on Python's asyncio library.

03 November 2015

David Beazley's curio library looks interesting. This is the most compelling example of async/await from PEP 492 that I've seen. I anticipate that this is the direction the asyncio standard library module will go.
The shifter I designed is now available on Mission Bicycles! More details on the manufacturing process to come.

13 October 2015

Learning new skills after a decade

This week is my 10 year anniversary of working as a professional software engineer. The advice I've followed is "always be the worst player in the band". But over time the meaning of that statement has changed for me. I've realized that there's a lot more to making music than playing the notes.

It sounds odd, but what I'm most excited about right now is learning to play the piano. Specifically: I'd like to play Jazz standards using a Fake Book. I can't remember the last time I learned a hard skill that required physical repetition and muscle memory. Maybe it was learning to drive a stick shift? Or do a kick flip? Or maybe Emacs key bindings?

Here are some of my favorite piano moments over the past 3 months of practicing:

  • Being able to read treble clef notes without making mistakes in this app
  • Learning enough music theory from this book to understand why chords work
  • Being able to play dominant, major, minor, diminished, and many other chord variations quickly
  • Learning about the cycle of fifths and using it to practice
  • Practicing scales enough that I can do it (poorly) with my eyes closed
  • Writing down my own ideal fingering for a sequence of notes
  • Learning the importance of proper sustain pedal usage
  • Playing a bunch of songs that I know

Here are things that I can't do yet:

  • Play the rhythm correctly
  • Know all chord inversions and be able to use them quickly
  • Play songs without looking at the keys, especially chords
  • Sing and play at the same time (I actually don't want to do this, but it seems like a good exercise)
  • Play classical music with a real bass clef
  • Make meaningful progress on Mark Levine's Jazz Theory book

Speaking of that Jazz book: I asked a musician I know for some advice on how to learn. He said, "I know just the book for you". He showed me "Jazz Theory" and I asked, "This looks great, but are there any other books I should read?" The musician's answer was, "No. If you wanted to learn about Jesus, you'd read the Bible. If you want to learn about Jazz, this is the book."

Why isn't there such an obvious go-to book in the realm of programming? I wonder who would disagree with my musician friend, why, and what book they'd recommend instead. Perhaps it's just the nature of learning: While you're inexperienced, people have amazing, definitive advice; once you know, everything is murky.

02 October 2015

Deleting code (exclusively) is my favorite thing to do on Fridays.

16 September 2015

Effective Python on the Talk Python Podcast

I had the privilege of appearing on the "Talk Python to Me" podcast this past week to talk about my book, Effective Python. You can listen to the episode here and the transcript is here. Many thanks to Michael Kennedy for hosting!

13 September 2015

Kerbal Space Program

If you haven't heard of Kerbal Space Program, the gist of the game is this: You play the role of NASA or SpaceX to design, finance, build, launch, and control rockets, spaceships, robots, and astronauts that explore the solar system. It sounds like a great idea that ends up being boring in practice, but they somehow figured it out — Kerbal is extremely fun.

I've been watching the game evolve since it debuted. I'm really cautious about playing games because I get obsessed and they take up all my free time (to the detriment of other things, like open source projects and my social life). But this summer I was looking for a new way to chill out. I decided it was finally the right moment to start playing.

Kerbal's graphics aren't the best, but the physics engine is great. You learn a lot about orbital mechanics by playing. In career mode it's a very difficult game. To get better at it, I spent a lot of time reading the Kerbal Wiki, watching walkthrough videos by Scott Manley and Billy Winn Jr, and enjoying the Kerbal subreddit. Did you know that Elon Musk plays Kerbal, too?

Some moments in the game that made me feel great:

  • Getting into orbit
  • Landing on the moon
  • Docking two ships together for the first time
  • Driving a dune buggy on another planet
  • Perfectly matching a satellite's orbital parameters

It scratches a similar itch to Sim City and Civilization. But it also feels like Minecraft in how creative and arbitrary the game is. I haven't even begun to explore the tremendous Kerbal mod community that exists.

Here are some screenshots from my most recent accomplishment in the game: going to Jupiter ("Jool"), landing on two of its moons ("Bop" and "Pol"), and making it back to Earth ("Kerbin").

I had to fly a big spaceship that's powered by a nuclear rocket. Look how stoked those Kerbals are, in the lower right of the screen, to be zooming off for a 10 year mission to the edge of the solar system:

Here I'm using the guidance computer to execute my burn. If you haven't played the game this will look insane. For someone who plays the game this is actually a trivial example:

And finally, here's what it looks like when the astronauts ("Kerbonauts") make it back home safely. Succeeding in getting them home is one of the best parts. (This was a night landing because I ran out of fuel and had to rely on aerobraking to slow down).

I've barely scratched the surface of this game. I can't recommend it enough. But don't blame me if it ruins your life, too.

09 September 2015

This article about SpaceX and their goal of colonizing Mars is the most inspiring thing I've read all year. It's long but totally worth getting through. It includes tons of great links, such as these travel posters:

Toyota is selling a hydrogen car now. Crazy futuristic time.

04 September 2015

Helpful perspective in the presentation called "Ten Things That Will Try To Make You Leave Technical Jobs", from the NYU/Columbia Women in Computing symposium earlier this year. Be sure to read the speaker notes.

15 August 2015

Growing giant sequoias

I saw some giant sequoias a few weeks ago. There aren't many of these 2000+ year old trees left. Growing more seems extremely difficult given all of the war, fire, and suffering that occurs on Earth during such a time period. With all our technology and sophistication we can send a probe to Pluto, but it seems impossible to grow a tree into old age. It's so simple, yet so difficult.

Time is not something we can control. Or is it? You can imagine launching baby trees into space and shooting them off towards the speed of light. Time would elapse faster for the tree than on earth due to special relativity. After a large orbit, the trees would return and be thousands of years older than when they left. Land them back on Earth, put them in the ground: problem solved.

It'd be a great way to age whisky as well. I wonder what kind of energy production breakthrough would make it possible.

Damn, my idea is totally not possible. I got the direction of time dilation mixed up. I'm feeling pretty dumb. Thanks to Tony for pointing out my mistake.

Well, since we're on the topic of humans trying to beat time anyways, I saw this paper from Sandia National Labs and it's extremely spooky: "Expert Judgment on Markers to Deter Inadvertent Human Intrusion into the Waste Isolation Pilot Plant". The fact that we're alive today as a species at all is remarkable.

14 August 2015

Effective Python video released this week

I did a video version of Effective Python! Here's the link to check it out. I also did a video interview with Addison-Wesley to talk about the book and related questions about the Python language:

04 August 2015

I enjoyed this talk about programming languages by Ramsey Nasser from Eyeo 2015:

11 July 2015

I'm a big fan of Amaro (the bitter aperitivo/digestivo). Here's an amazing guide (parts 2, 3, 4) to all the different types!

18 June 2015

Wonderful post by Ade Oshineye explaining the evolution of what the web is. Must read.
WebAssembly is happening! From that post:

I’m happy to report that we at Mozilla have started working with Chromium, Edge and WebKit engineers on creating a new standard, WebAssembly, that defines a portable, size- and load-time-efficient format and execution model specifically designed to serve as a compilation target for the Web.

Watch The Birth and Death of JavaScript to understand the long-term vision (no joke).

12 June 2015

Mesosphere's "Data Center Operating System" is now generally available. The case studies from that post about Twitter, Yelp, Apple, and HubSpot are especially interesting.

09 June 2015

I wish these stats were built into my email client: "Three Years of Logging My Inbox Count"

08 June 2015

Wonky Swift 2.0 code sample

Swift 2.0 is out. What's up with this bad indentation in the code example? Oh it's just Chrome not following web standards dealing with the \ufffc replacement characters in the byte stream from Apple's webserver. Probably a bad copy/paste into the marketing materials. Interesting that Safari and Firefox don't care ("be liberal in what you accept").



"Organizational Debt is like Technical debt — but worse" explains a lot of what I've seen as engineering teams grow and change.

06 June 2015

Python 2.7.11 will be 15-20% faster by using computed gotos instead of a switch statement, thanks to a patch from Intel. Edit: To be clear, it's the bytecode interpreter's code that's faster; overall benchmarks are here.

04 June 2015

I'll be speaking at the Bay Area Python Interest Group on Thursday, June 25th in Mountain View at LinkedIn. See the details here. Hope to see you there!
I'm attempting to translate the items from Effective Python in to best practices for Go. My first attempt is "Know When to Use Channels for Generator-Like Functions".

02 June 2015

This book (in progress) looks great: "Model-Based Machine Learning". Written by two researchers at Microsoft.

27 May 2015

Two amazing posts by Martin Kleppmann:

The illustrations are great, too. Looking forward to reading his book (in-progress).
Helpful presentation by Adrian Cockcroft (formerly of Netflix): "Monitoring Microservices and Containers: A Challenge"

26 May 2015

Go 1.5 is coming

I went to the Gopherfest event tonight. There's a lot to be excited about in Go 1.5. The freeze is now. Release is due in August. Be sure to check out Rob Pike's talk about "Go in Go" and Andrew Gerrand's talk about the "State of Go" (May 2015 edition).

But I'm especially happy to see things like this:

Here's a cool post that demonstrates the differences between interpreters, compilers, and just-in-time compilers. My first exposure to this was the dynamic recompilation that some Nintendo emulators would do for speed. At the time I didn’t realize that it’s pretty much the same thing as JITing.

16 May 2015

Evan Miller — always a treat — writes about Rust.
REST : RPCs :: Functional programming : Imperative programming

13 May 2015

Updated my Chrome extension "Clip It Good" to v0.4.1: It lets you save images and GIFs from webpages to Google+ Photo Albums.
Two Python Neural Net / Deep Learning projects worth checking out: Keras & PyNeural.

One uses Cython for speed, the other uses Theano. Fun times!

10 May 2015

Wonderful answer to "What is the appeal of dynamically-typed languages?"

Erik Osheim's post, "What is the appeal of dynamically-typed languages?", is one of the best explanations of the value of dynamic languages that I've ever read. This is the kicker for me:

One advantage Python has is that this same faculty that you are using to create a program is also used to test it and debug it. When you hit a confusing error, you are learning how the runtime is executing your code based on its state, which feels broadly useful (after all, you were trying to imagine what it would do when you wrote the code).

By contrast, writing Scala, you have to have a grasp on how two different systems work. You still have a runtime (the JVM) which is allocating memory, calling methods, doing I/O, and possibly throwing exceptions, just like Python. But you also have the compiler, which is creating (and inferring) types, checking your invariants, and doing a whole host of other things. There's no good way to peek inside that process and see what it is doing. Most people probably never develop great intuitions around how typing works, how complex types are encoded and used by the compiler, etc.

This logic also explains why Go is so easy to write and probably accounts for its astounding rate of adoption. It's so much easier to master both the running Go language and its type system compared to other statically typed languages.

Erik's answer also puts last year's popular posts, "Why Go Is Not Good" and "Go's Type System Is An Embarrassment", in perspective. The authors of those posts don't appreciate how many people have trouble understanding complex type systems. A lack of understanding prevents programmers from using such languages effectively, which reduces overall adoption.
Interesting survey on the adoption of Python 3 vs. version 2 by scientists.

09 May 2015

Exceptions are a crucial part of a function's interface. Isn't it strange how Python's type hinting leaves them out?

04 May 2015

Please vote for my EuroPython talk and others!

I submitted two talks for EuroPython this year (July 20-26 in Bilbao, Spain). They've just opened voting to existing ticket holders. If you've already bought a ticket, I'd really appreciate your vote on one or both of my talks! (You can also buy a ticket here). You should also take the time to vote for the other submissions you like. There are a lot to choose from!

To vote, first you need to login following this link. Then you can view the talk index, visit the talk pages directly, read the abstracts, and click on the voting stars on the right side of the page:

My two talk proposals are based on the content from my book, Effective Python. You must be logged in or else these proposals will look like dead links:

These will be in the same style as the talk I gave at PyCon 2015 this year, but the content will be completely different. Hopefully they'll end up accepting whichever of my talks that has the highest rating. Thanks in advance for your support!
© 2009-2016 Brett Slatkin