Wynn Netherland Author, Full-stack Developer at Github

Wynn is a full-stack developer, but prefers to play where the user meets the machine. He’s worked in huge companies and small startups, but prefers smaller sized teams of five or less.

He currently works at GitHub on APIs and other things. He has co-authored or contributed to several books, including Sass and Compass in Action, Open Government, and ASP.NET Custom Controls.

Watch the Interview

Listen to the Podcast

You can subscribe to this podcast on:

Show Notes

[01:50] How did you get into GitHub?

GitHub had an API wrapper called octokit, it was a really base wrapper. At the time there wasn't too many idiomatic wrappers for the GitHub API, and this was for the first version of the API not the one we currently support. I was building a good deal of mash-ups, I was involved in the Twitter gem, John Nunemaker's Twitter gem for pulling data out of the Twitter API. When I started poking at the GitHub API I didn't like any of the ActiveResource style wrappers that were out there, so that got me into building parts that I needed to consume the GitHub API. In 2012 I was invited to interview, I found that octokit was used inside of GitHub, had I known I probably would have put a little more love into it.

[02:52] Since then, what have you been working on in the GitHub team?

I work on the platform team, so it involves the API but also involves the oAuth system that powers the authentication system. Dabble a little bit in hooks and other platform features, security enhancements and things of that sort. New features in the API, keeping the lights on.

[03:20] What do you think makes a great modern API?

We put a lot of emphasis on REST and JSON and providing URL affordances for clients to discover what's in the API and make those calls. Honestly, there are still a lot of API's regardless if you are using traditional REST or XML-RPC, theres just a lot of HTTP plumbing that a lot of API's just don't do. For someone to consume your API there are some things you can do to make it easier for them is to lean into error codes. An on-going challenge is when you come up with a new state or condition trying to figure which HTTP code it maps to. JSON Schemas are another tool that are helping quite a bit. JSON is typed, but it really doesn't have a shape. We're used to XML having schemas that declare what are valid values for some of these types and JSON will give you primitives but it doesn't really tell you how big the integers can get, if something is nullable, things of that sort. JSON Schemas patches that hole, both on the input and output side, helping make an API more modern.

[05:19] What makes a great API wrapper?

First, the octokit project is a great community project, Erik Michaels-Ober and some other folks have done a great job of contributing to the project, I don't want to act like I wrote every line of code in that. But I have written a lot of wrappers, and consumed a lot of API's, for me making a wrapper idiomatic to the language you are writing it in is, far and away, the biggest thing you can do to make it easier for clients. If I'm writing Ruby I want it to feel like Ruby, I don't want to have to know the details of the ReST calls I am making behind the scenes. There are certain language constructs you can lean into to make it easier to feel at home in the language you are working in. Especially with Ruby you can create DSL's and nice chained methods that do a number of things that feel very "Ruby-ish" whereas if you are in Go you may want to keep it more error handling driven. If you are exposing an API snake-casing your JSON keys, for example, is one way you can help clients build idiomatic wrappers and not have the details of the API bleed through. There are so many wrappers that take an API method and simply wrap it instead of extract it, I think abstraction enables workflows and you can stitch together methods internally and not really worry about API method you are calling behind the scenes.

[07:17] For those who might not be familiar, what is "snake-casing"?

Snake-casing is just using underscores to separate words, opposed to traditional "camel-casing" (which uses capital letters to separate words). We use camel-casing in a lot of languages for methods and variables, but in JSON snake-casing makes it easier to parse what those keys mean.

[07:35] Are there any open source projects, if you were starting today, you wish you had known about?

If you are going to build an API you need to know curl. I put in the signature line of the GitHub support for the API "curl -v or it didn't happen". Which basically means send me some verbose curl output to verify that what your claiming actually happened. Mastery of curl will go a long way because it is the lingua franca of API's. Given that I use curl so much, some tools that I couldn't live without, one is jq. The tagline on the project is "the real jQuery", to install on a Mac just brew install jq. Once that is in place it is just a stream parser for JSON that makes it really easy to make a curl call and pipe it to jq and provide a filter, you can then pull back parts of the JSON. grc is another one. If you want to colorize output in the shell, I use this tremendously. I even have a curl alias that maps it through grc so that curl output comes back color coded, which makes it easy to see header values and header names and syntactic highlighted JSON results, which is pretty cool.

[09:17] Are there any frameworks for writing API's that you like?

I'm a pretty close to the metal sort of developer, in the past I have explored frameworks that supposedly made it easier to annotate attributes in your model and expose those via an API. One of the things that more senior developers at GitHub have taught me to appreciate, is decoupling your API from your actual website. That allows you to move independently in changing one side or the other. You can share certain layers of code, at GitHub we share the models and we share the lib folder, but we have different presentation layers. There's a Rails controller that serves up the web and we have an embedded Sinatra app that serves up the workflows for the API. This gives the best of both worlds, you don't have to be worried about ripping out features in the website affecting the API, we can leave the parts that we need to keep the lights on over on the API side.

[10:25] Have you explored other programming languages for building API's?

I just started to build some streaming stuff, just experimentation, in Go. I really love the concurrency model in Go. It's not Ruby, sometimes when you switch languages there's a whole mental paradigm shift that has to happen. I've written some thing to consume API's, in Ruby and JavaScript and Go. I just think in Ruby now, it is my first language by far, but I do love developing in Go. One of the reasons is that, because it is statically typed, it helps us remember that when we are building API's to keep those static clients in mind. It's so easy if you have a dynamic background, Ruby, Python, JavaScript to start returning nil for a field. Not thinking anything about it, and not realizing that statically typed languages, C#, Java, those have to take care in those types of values. The takeaway is that one of the greatest things you can do to build a great API is to dogfood it. One of the things I like about working on the GitHub API is that we use the GitHub API to build GitHub. So we have tremendous opportunity to dogfood the API and to figure out if this workflow makes sense for consumers because we are also a consumer.

[12:02] How would you explain Go to a Ruby-ist? Are there analogies you can use to explain Go to non-Go people?

Simple goroutines and the way you can write to channels makes it extremely easy to have just enough concurrency without having to constantly track. It's almost like garbage collection in modern languages, you don't have to count references anymore. Goroutines brings that sort of programming model to concurrency. One thing I like about Go is its terseness, I guess that's a two-edged sword. There are certain things that rae more verbose in Go and certain things that are more terse. One of the things that took me some getting used to coming into Go from Ruby, in most object oriented languages which Go really isn't, it is object based with structs, in most languages your indentation level drives the "where am I?" question if you jump into a file. In Ruby it is usually two white spaces, based on that indentation level I know if I am inside a method, inside a module, inside a class. With Go, since you essentially create structs and then you graft on methods on the outside kind of like an exoskeleton you have to read the full function signature to figure out what am I adding this behavior to. And there is no enforcement in there that says this file should define this type and only one type. So, depending on the project you can come in and there is multiple types and multiple methods being grafted onto that particular type in the same file, it can get kind of hairy. Go is still learning what the conventions are, as great as Goformat is there are still some things that it doesn't catch from a style-guide standpoint.

[14:33] People might have heard about dotfiles but not everyone has toyed with them yet. Can you explain what dotfiles means and about automating that for developers?

From a tool standpoint my background is in graphical user interface tools. There was a time when I could do anything without a right-click property pane. Microsoft was notorious for having things that were hidden away in some component manager, some MMC control, that you would have to open up and do some config setting. When I jumped into the Unix world with Ruby on Rails everything was driven from config files. It has been a natural progression, that you could configure these tools and most had an rc file or some sort of dot file that lived in your home directory that you could provide defaults to, when you started the tool you could provide your own preferences. Its essentially a preference pane stored as text inside of your home folder. Zach Holman, at GitHub, first turned me onto dotfiles because of his article Dotfiles are meant to be forked. This was several years ago and it got me thinking. I was part of a podcast, Changelog and we started interviewing folks that were prolific in the vim community and that got me into developing with vim. Now that I had my text editor in the terminal what I really wanted was to stay in the terminal all the time. When you start a new Rails project you need an editor, you need a shell terminal to execute commands, you need to crank up a server, you need a console for REPL, sometimes you want to tail a log, so you have 5 or 6 environments. I got weary of flipping the command tab merry-go-round to go between the editor and the browser and a SQL GUI tool so I was on a quest to get everything into the terminal. The holy grail for me was finding two things. tmux, which is a terminal multiplexer that stitches all of these terminals together so you can have one logical terminal session and have workspaces per project, but now you can create these statefully. Mislav, who works at GitHub, has a great hack that, its in my dotfiles if you want to check it out, that allows you the seamlessly navigate between tmux panes and vim panes. That really tied it all together so you can create your own IDE in the shell. Dotfiles are just a way to specify all those preferences and bring your own shell scripts to craft your own IDE. If you want to get started go to dotfiles.github.com and there are some frameworks that we feature there and some introductory material that will help you get started. If you are new to the shell, if you are a designer or front-end developer and are used to GUI tools and you want to jump into the shell, start with a framework. Janus, or something like that, and just playing with other people's curated defaults.

[18:43] What are some of the best tools out there for developers to automate deployments with?

Jenkins is at the top of the open source list as far as running continuous integration tests. I'm still surprised in talking to people how many development teams don't use even source control, CI is the next logical step to make sure your code is working with the rest of the team and you are not stuck running a 15 minute test suite on your local machine between changes, that can get very tedious. The idea with continuous integration is to let a server take care of that, you just push your branch to the repository and some scripts kick off, magic happens, and it tells you if it passes or fails. Janky is our tool that we have built on top of Jenkins, it adds a more simplified GUI on top of Jenkins. The GitHub API also has a couple of API's that power our implementation. One of them is the status API and this is where it began. The ability to mark a particular SHA, a particular commit in a git repo as passing or failing a series of integration checks. We have three or four environments that our source code has to deploy to and so we have to make sure they run in those three or four different environments, they all have to come back and vote as a unit so it is not done until it passes green in all the environments. There's also the deployment API that can also be configured to roll branches into particular environments and report back to GitHub that these particular bits have been deployed to these environments. Some services that will do this for you, Travis CI is probably the most popular especially for open source projects. CircleCI is very popular as well, for both open source and closed source.

[21:07] You've written about Hubot, can you tell us a little about that?

Hubot is a snarky little robot that the folks at GitHub built that hangs out in your chat room. He does some important work, some critical work, and then some just nonsense work. He listens just like an IRC bot for commands. We use it for everything from pulling up visualizations of metrics that we track to see how certain endpoints are performing, to track anything that we have instrumented in our code. We use it to pull up logs, investigate logs using Splunk, which is pretty cool. He can also do other really important things like pulling up animated GIF's and insult other people. He's got an attitude, so if you cross him he'll tell you to come at him.

[22:00] Have you read any interesting books lately?

I'm working my way through Creative, Inc. the Pixar story. I'm a history buff so I love how that's framed from a historical perspective. From a technical book standpoint, some of my favorites lately have been Building Awesome Command-Line Applications in Ruby, Practical Vim is another one, there's also a great book out there for Tmux. For the most part I get most of my technical content from blogs. My form factor for consuming technical materials is pretty much blog format, I really dig that.

[24:00] Are there any blogs that you recommend?

The Thoughtbot blog is excellent. NShipster is great for Objective-C and now Swift. Coding Horror is definitely a classic. Inessential is really good. One of the blogs that I find interesting, less so on technical material, Adam Keys blog The Real Adam. His blog is usually full of softer topics and I think that is one of the things that as I age in development I am less technical focused and more people focused. I still dig tech, don't get me wrong, but I am more into what is stable than what is new. And I am finding patterns, from developers way smarter than me, have been around forever. So I have been on this trek to find what has been around, what's still used, and to use that more and more.

[25:30] Have you discovered any cool open source projects lately that you're excited about?

Yeah, I subscribe to the GitHub Explore mailings and I find this is the best way to find cool open source projects because it will mail you a daily list of what's popular, what's trending, what the GitHub staff has starred, and what folks that you are following on GitHub have starred which is pretty cool. One of the things I have been playing with lately, and like any good open source project its like "Hey I found this great tool and I'm not sure how you pronounce it", is vedeu. It’s from Gavin Laking and its a cool DSL for creating command-line, stateful, ncurses style apps in the shell. As I mentioned before, I hang out in the shell quite frequently and so, with a 30 in monitor you just have tons of real estate to crank up a new tmux bay and put something over there, so I stream Twitter with Twitter command line clients and things like that. I'm interested in building a heads-up display for critical metrics from a workload standpoint, API bugs that are open, help tickets that need answering, things of that sort.

[27:17] What do you think is next on the horizon for modern web app developers?

I think web components are interesting. I have a healthy skepticism based on micro-formats and some other things that supposedly promised similar things years ago.

[27:40] How are they different than micro-formats?

They are a little bit more codified, a little bit more isolated, sandboxed, things of that sort. I remember back in the C# days of getting the component source catalog and drooling over gauge controls from third parties. Going to our manager and saying "hey, we just need $4000 for this particular slider control so we don't have to write it". Not sure if we will get there from the web standpoint but it is interesting to see how many times we are going to reinvent certain controls. Even to the point where we are still trying to style away browser specific styles for form controls. I'm interested to see with these more sophisticated types of controls how the community is going to build those and what that will turn into.

[28:39] Do you see any open source projects around that, that you are interested in?

Webcomponents.org is the website, I've been playing with some of the gallery controls, mostly just piddling. One of the things that does interest me is the upcoming spec for window.fetch which should simplify AJAX calls in the browser and have them consuming polyfill, that David Graham and others have created. There is a polyfill on GitHub that should conform to that API making AJAX calls easier for some simple cases. To be honest, in terms of trends, is figuring out more "people hacks" and the community. How do we find mentors and how do we bring along junior developers. Once you hit your mid-30's what does the road look like for you as a developer, if you want to stay creative, if you want to stay productive without being set out to pasture as a manager or something like that. I'm interested in finding folks that are further up the road, that have done that, and have stayed relevant and stayed happy. I think a big part about trends in tech is like life, it is the people involved.

[31:00] What's your best advice for a junior developer to think ahead of the future?

To not put your hope in projects and to view tech, like anything in life, as a medium for relationships. Work on the soft skills just as much as you work on your development skills. It's easy as a young developer to have this toxic combination of arrogance and ignorance, we were all there at some point, as you age a bit you figure out "wow, I don't know anything". Which is a healthy thing, now you know how to get off the happy path and how to keep others from failing spectacularly.

[31:42] What would you say are one or two soft skills that might be the first to work on?

Empathy has always served me well. To think about who is on the other side of this API call, on the other side of this screen I am building, why are we building this, what problem are we trying to solve with this particular page instead of just cramming more info on it. But also exercise some empathy. If I were consuming this API call, regardless that this API call has met the specs that we set out at the beginning of the sprint, can I do the meaningful work that we intended on the other side? If I am going to change this API call what impact will this have on other people's businesses? Being able to empathize with other is critically important. Communication skills. Being able to explain ideas and that just comes with seeking to teach. Don't be afraid to speak at a local meet-up or something like that, doing that will help you hone your thinking.

[33:14] Those two things are what separates a good developer from a great developer.

One of the things that I've talked to people about the same issue, one of the things that I have found is that sometimes people feel like, "oh, I'm a junior developer what can I teach anybody?" To those people I always say, "just write down your journey." It doesn't matter if you think you sound stupid because you are just learning. There's always going to be someone who comes after you who knows less than you. Think of yourself as writing notes to help the future version of yourself, you can begin honing your communication skills this way. That's great advice and if you find that you're not being stretched and you are the smartest person in the room, seek to get to somewhere that is stretching you. The flip side of that is impostor syndrome, its easy to get into a place and feel "I really don't belong here". Just realize that you have something valuable to share, that the specialized expert in this field probably doesn't know the ins and outs of what you were hired to do. Have some confidence and some humility and it'll work out.

Quick Links