Tell me about yourself and how you got into development (first coding experience, school, work, etc.)
Tell me about Express.js. How long have you worked on the project? Where did the idea come from?
I started working with a team on a new web application in 2009 on Node.js. Back in those days Node.js was still in a very early form, and when npm became viable not long after starting, the application was moved to the Express.js framework. I worked with my team on developing this application, and over time watched really closely all the dependencies we were pulling in, getting involved in their issue trackers, making pull requests, etc. Express.js in particular took my eye because (1) it was an area the interested me (network communication protocols) and (2) I felt like I could chime in on issues opened and PRs to provide answers that would better reflect the proper ways to use HTTP. Express.js was a project I got involved in, rather than one of my own creation; TJ Holowaychuk has the honor of creating the framework and getting everything going and making it was it was.
Do you still work on Express?
Yes, Express is the main system of modules I work on in Node.js. This includes issue triaging, releases, fixes, improvements, helping others, etc.
What do you do now? Is there anything fun or exciting that you’re currently working on?
In open source, I am working on Express.js and the MySQL Node.js driver, both exiting things to work on for sure.
What do you like most/least about development?
Development is great, especially getting to think about problems, coming up with ideas for how to solve them taking into account the use-cases and just generally the feeling of “hey, I did that!”. On the other side, working development can be a drain with changing priorities and balancing lots of different needs with only finite time.
What technology do you currently find exciting?
I think Node.js is certainly exciting, which is why I’m so involved in the open source community of it. Node.js has been growing fast, and I love teaching others about it because I think it is generally a pretty approachable non-blocking network I/O system, and I like to live in the network communications area. Much easier to get others into learning the protocols with Node.js vs a language like C, at least that I found.
What are you really looking forward to in the future?
I’m really looking forward to what the Rust language is going to become and how that area may perhaps replace C as a standard language for the low-level network protocol glue.
What question do you wish someone would ask but never do, and whats the answer?
I think a good question is how much time I spend in open source and what a good way to get involved is. I spend a lot of time, with the majority is simply helping others, triaging issues through GitHub emails, and following conversations in IRC / Gitter. Great ways to get involved is not necessarily in the code, because especially in established projects, there isn’t a lot of code to actually get involved with (which in the ends, turns away potential contributors). Helping in issues and just talking with users and each other is the best way to get involved, and is exactly how I got started in the Node.js open source as well. There is some code here and there, but a lot is just helping and from that is where the really ideas for what code changes to make usually come from that are useful.
What are some of your hobbies? How do you spend your free time?
I do spend a lot of my free time working on open source work, primarily Node.js. Other than that, I spend time on aquariums, video gaming, and light outdoor activities.
What is something you like to talk about or do that you don’t get the opportunity to?
I haven’t done much public talks in general, but I really want to talk to developers about topics that I usually find experience lacking like testing practices and security in development.
What advice would give to other developers, or general wisdom you would impart to anyone?
From everything a developer may need to know to be really successful, I think the one best recommendation I can make is to make it a mission to truly understand and be able to articulate issues you have and resolved. In my experience, I think that the developers who are able to articulate why they had some issue and why exactly a fix actually solved their problem really sets them apart, and is more useful than raw knowledge.