Have you ever meet a brash punk kid that annoys you to no end but he's so damn talented that you can't help but want to work with him? That's how I felt when I first met David Walsh several years ago. Since then, I've seen him mature into a respected and often quoted software developer and most recently, a new dad. He hasn't lost his snark and feistiness and he continues to hone his skills daily, often sharing his best tips on his awesome namesake blog.
It's time to get a little more info on what makes David tick and I had the opportunity to hit him with some tough questions.
Q Silly question, but why did you go with a ".name" domain for your blog?
My blog's domain was originally "bludice.com", but I decided to brand the blog after myself since BluDice doesn't mean anything and it certainly wouldn't help me in my career path. All of the relevant .com's were taken and since I wanted to brand my blog after myself, .name just seemed to fit. In hindsight, I should have tried harder to find a .com. I bought "david-walsh.com" a few years ago, so maybe I'll migrate to that some day.
Q When we first met, you were a big proponent of MooTools. Are you still involved with the project?
I'm not involved in the project anywhere near as much as I used to be and not as much as I would like to be. Job circumstances (working at SitePen for two years, which is a Dojo shop) took my attention away from MooTools. I'm still in the MooTools development IRC channel each day and still keep up with where the next version of MooTools is at, so I'm involved enough to know what's going on at all times. I also hope to make it to the next MooTools Hackathon in London.
Q It's safe to say that jQuery won the hearts of most web developers. How did that affect the roadmap for MooTools?
MooTools was created to provide a modular, compact, Class-based JavaScript utility, which was different than jQuery's goal at the time. jQuery's popularity didn't affect the MooTools roadmap at all. MooTools' goals and mission never changed beyond what we set for ourselves. Developers believe there is a competition or hatred between the JavaScript frameworks, and it simply doesn't exist, nor did it ever.
Q There was always this "thing" between the jQuery & MooTools teams (I like to call it hyper-competitiveness). It seemed like both should've been able to co-exist but it didn't quite always work out that way. From the MooTools perspective, what were the underlying issues you saw?
Creating crap code is possible with any framework…
I can't answer this for the MooTools team, so my answer strictly represents my own thoughts. The tension between jQuery and MooTools was built up by members of the community, not necessarily the team members themselves. Maybe there was more on the jQuery side, but I know that we didn't give jQuery much thought.
The main issue that jQuery has fought, from the perspective of other JavaScript framework users (not just MooTools), is that the low barrier of entry enables "n00b" developers to create a lot of unoptimized, crap code. Creating crap code is possible with any framework, but the other frameworks required more JavaScript knowledge and thus were more able to avoid this problem, to a degree.
I also get the feeling that other framework users get hung up on jQuery's popularity and seeing it as an inferior toolkit; i.e. the "McDonald's" analogy that they're super popular but that doesn't make them good. Unfortunately in my experience in having worked within a whole bunch of different JS toolkit communities, jQuery seems to get the brunt of negative comments.
I've been long accused of being a "jQuery hater", and while I'll admit that jQuery isn't my cup of tea and I don't choose to use it on my personal projects, I far from hate jQuery. It's a tool, like any other, it has been hugely helpful to millions of developers around the world, and that's something you must respect.
Q Even while on the MooTools team, you created quite a bit of jQuery content. How did that go over with the rest of the Moo team?
Aside from the locker room ribbing that I'm sure comes with being a part of any group, no one said anything, and why should they? In reality, creating mirroring tutorials and demos with both jQuery and MooTools helped to bridge the perceived code gap between the two frameworks, and hopefully got users of each framework to try the other. I learned a lot from the experience and hopefully others did too!
Q I think people take for granted how hard it is to manage an OSS community. What were the challenges you faced as one of the more active team members?
There are a number of challenges that come with being an active member of an open source community. Organization is incredibly difficult because you must deal with language barriers, cultural differences, time zone differences, and interesting personalities. You also need to keep in mind that OSS work usually isn't a developer's primary job (thus they aren't getting paid for the OSS work) and that they also have a family to spend time with. And of course, most OSS devs just want to develop and not promote or formally release work in a timely manner.
To succeed in open source communities, it's important to be understanding, patient, and willing to work with different types of people. Everyone has a good heart, and everyone wants to succeed, but each brilliant dev has their own route of getting there. Once you learn to manage your contributors, your project will succeed and more contributors and users will flock to you!
Q There's a big push in the industry away from libraries and frameworks, instead focusing more on pure JavaScript. How do you see the two blending? It seems they should be complementary, not one or the other.
In a perfect world, JavaScript framework users would use the modules they needed and would avoid massive load.
They should be complimentary, yes, but there are a few problems that we've seen since the explosion of framework usage. The first problem is that developers will include an entire framework (animates, AJAX, etc.) just to solve one problem, and thus bloat their website tremendously when a microframework or a few lines of pure JavaScript should do the trick. Another problem is that relying on frameworks and their abstractions prevent the developer from truly increasing their JavaScript skills.
In a perfect world, JavaScript framework users would use the modules they needed and would avoid massive load; unfortunately that isn't a common enough practice today. More and more developers are adopting this practice though, so I'm hoping this won't be such a debate in the future.
Q How do you see the new features of ES6 affecting the functionality of existing libraries? Will we see them become more specialized?
They'll have to become more specialized and evolve or they'll find themselves irrelevant. Of course, we all know how long it takes for browsers to implement these types of new features, so we're assuming the same JavaScript frameworks will be there at that time. The main thing we can count on, however, is that evolving is the only way for any project to survive.
Q Your work at SitePen allowed you to dig deep into the Dojo framework. What do you think is the reason that it didn't pick up the level of traction of other projects like jQuery, Prototype and MooTools, especially since many of the features we promote today were in Dojo for some time?
Some JavaScript frameworks are heavy into promotion and some aren't. Dojo developers definitely aren't. Dojo also had a stigma of not having good documentation, which may have turned people away. I would also argue that Dojo's always been more focused on building feature-rich "web apps" rather than basic websites. Dojo's documentation has gotten much better and they continue to push the client side boundaries more than most JS toolkits, so I would really encourage developers to give Dojo a shot!
Q Now that you're at Mozilla, have you seen any major changes in the way you structure your development considering you're working on a large web property and you're remote?
Being a remote developer doesn't play as large of a role as most would think.
Going from creating private, internal web applications to working on an important website that gets millions of views each month forces you to reevaluate your development process. The MDN (Mozilla Developer Network) team has adopted a frequent release cycle, pushing code updates many times a day. Spot checking and unit tests become increasingly important as we add features. Localization plays a massive part in MDN development too. Each piece of code requires a lot of thought, so we do code reviews before merging any changes.
Being a remote developer doesn't play as large of a role as most would think. Our QA engineers and IT team are always there to lend a hand. Mozilla has made remote development a breeze.
Q How does the dev team at Mozilla collaborate so well, especially with many being remote?
Mozilla does well in recruitment so I work with dozens of brilliant, dedicated, and responsive developers. Most communication is done via IRC and Bugzilla tickets, and we're never shy about jumping on Vidyo or Skype to get some face-to-face time. Remote employees have weekly 1:1 meetings with managers to ensure everything is going smoothly. Most teams have a bi-monthly meeting where the team can discuss what progress has been made and what goals should be tackled next. Mozilla provides the perfect balance of freedom and structure, which is the main reason I'm so happy to be a Mozillian.
Q How has Mozilla's mission and altruistic nature affected the way that you look at software and contributions to the community?
Mozilla's support of open source and going the extra mile to improve the web have changed my thoughts on OSS development immensely. My colleagues are an inspiration and that energy is infectious. Most of my colleagues have popular open source projects and are happy to jump in and help when needed. A majority of Mozilla websites and back-end apps are hosted on GitHub, even sites like the Firefox Marketplace and Mozilla Developer Network, so basically everything is available to the community. When I got to Mozilla, I was surprised at how many contributors there were to the Mozilla family of websites. I loved the Open Source community and my experience has taken that love to the next level; I cannot imagine working on proprietary programming ever again.
Q You had a recent addition (congrats!). How have your work/life balance considerations changed now that you're a new dad?
Having a child puts life in perspective. Most nights over the past five years I would get done with work and then spend the rest of the night on my computer writing blog posts. I got a lot out of doing that, but I would frequently get burnt out. With Jack around, I'm happy to not spend so much free time on the computer, and instead opt to take him on walks, take him to visit his grandparents, and generally just get out of the house. Seeing your kid smile makes you realize there's more out there than loop optimization and dealing with negative tweets.
Q How do you detach from work considering that you're a remote employee?
Working from home is sweet; I get to save money on gas and food, take a walk when I get frustrated, avoid distractions from coworkers, set my own work schedule, etc. The biggest drawback is working too much, which is something I've been guilty of for years now. Just like moderating anything else, however, you need to get into a routine and cut yourself off at a given time. You should also cut yourself off when you feel the icy glare of your spouse… :)
Q Do you see yourself pushing your son into programming? Why or why not?
Let’s be honest, we have a pretty good gig.
If he has interest in development as he grows up, I certainly won't push him away from that career path. Let’s be honest, we have a pretty good gig. We can (sometimes) work from home, make good pay/benefits, travel around the world, make extra money consulting from home, and generally won't have a problem finding a job. Tech jobs come with all of those benefits.
Of course programming comes with its drawbacks. There's a lot of negativity in the JS community, remote collaboration can be a nightmare in some situations, and clients oftentimes don't understand the work that goes into creating a solid site/app, so justifying price becomes difficult.
In the end, if it's what he wants, I'm happy to help him along the way.
Q You've managed to successfully monetize your blog. Are there any secrets or tips you'd care to share for those looking to do the same?
My advice is two-fold. First, choose sponsors which are good matches for the main topics of your blog. Second, don't overdo ad placement, remember that ease of consumption is still the most important thing. Writers should also avoid animated GIF ads, text link ads, and auto-playing videos. As your site continues to be usable and you put up content regularly, the income will arrive.
Q Some people discourage bloggers from posting advertising. How do you rationalize placing ads on your site and how do you determine if a specific ad campaign is something your readers would even want?
I get incredibly annoyed with people who assert that a blog shouldn't have advertisements and for so many reasons that I could go on for hours, but a few brief points are:
Criticizing someone else for how they make their money (assuming it's legal) is a really embarrassing thing to do.
Developers that spend hours writing tutorials, providing bug solutions, and providing code inspiration should be rewarded in some way, it's essentially another job.
The alternative is not blogging and instead doing freelance work, which helps only the client. Blogging ideas and solutions helps thousands of people and at no direct cost to them.
If I were to ask my wife and newborn what they thought about "@somedude on Twitter in godknowswhere" criticizing me for having ads, they'd laugh. They want to be financially supported, they don't care what a stranger thinks about it.
Too many people confuse open source with "free"; i.e. the code is free, everything else should be free. That's way off base.
Picking a campaign is usually the easy part. You accept adverts from businesses you've used, believe in, and are reputable. Stick to those rules and you're bound to do OK.
In the end I don't understand people who feel the need to comment on how others make a living; it's petty, rude, and again, embarrassing.
Q You recently added forums to your website. Forums management takes a lot of work. Why would you take that on when there are so many established support forums available?
I created a forum section for a few reasons. The first reason is that since the official MooTools-hosted forums were taken down, and the "unofficial hosted forums" were taken down, there's been no central place for MooTools users to get support. I also want to establish a more community feel to my site. Lastly, I get probably a dozen emails per day asking for help with a jQuery snippet, PHP problem, or follow up to a specific blog post. I'd much prefer those questions be posted to the forums so that (1) another user can help out if I can't and (2) I can avoid receiving and sending the same emails. It seems like a win-win all around.
In Closing
Thank you David, for participating in this interview. We really appreciate it.
To connect with and learn more about David, be sure to check out his website.
Original Link: http://feedproxy.google.com/~r/nettuts/~3/hgIOF9LAb4Y/
Tuts+ is a site aimed at web developers and designers offering tutorials and articles on technologies, skills and techniques to improve how you design and build websites.
Tuts+ is a site aimed at web developers and designers offering tutorials and articles on technologies, skills and techniques to improve how you design and build websites.