There are certain people in life that you leave a profound first impression. Cody Lindley is one of them. Opinionated beyond belief but incredibly insightful in his observations, Cody is the type of person that makes you want to have deep conversations not only about development, but life.
Couple this with the fact that he’s developed a solid reputation for his great front-end skills and has authored highly-regarded front-end development books and you’re sure to get one heck of an interview.
Sure enough, you’re in for a treat here as Cody talks about his persona, feelings about managing critics, and how to push yourself to be a better developer.
**Q: Hey Cody, can you tell us about yourself?**
**Q: Let’s talk about jQuery for a bit. Being intimately involved in the early days of the jQuery project, I can say that your [ThickBox jQuery plugin](http://codylindley.com/thickbox/) was one of the biggest jumpstarters for jQuery. Did you feel a lot of pressure because of the success of the plugin (e.g.: supporting it, community feedback, et al.)?**
No question that the success and its corresponding requests for support (I received calls from all over the world at all hours of the day seeking support over the phone on the spot) generated a great deal of pressure. This aspect of writing Thickbox was not much fun for me, considering that my intentions in writing Thickbox were [to highlight the value of jQuery](http://codylindley.com/thickbox/#support) and not to provide a specific tool. I wanted the solution to be a starting point, not an end point.
Now, what actually occurred is people threw Thickbox in the toolbox and implemented it heavily as a solution. Looking back, I can understand why this happened, and four things come to mind that I did not consider when releasing it. One, people's hatred for browser windows and the need to avoid using them. Two, just how badly the community needed a DOM based modal window that did more than displaying an image. Three, people’s innate desire to avoid thinking and favoring thoughtless implementation. Four, the power of being the right solution at the right time. All of these factors contributed to my original intentions being secondary to the masses that found and used Thickbox. But I honestly don’t want to complain. Both good and bad come from the rise and fall of Thickbox.
**Q: Even though ThickBox was a complementary plugin to the jQuery library, I imagine that you learned a lot about managing an open-source effort, even at a smaller scale. What were the important things you learned during that time and how did being a part of the jQuery ecosystem contribute to what you learned?**
Lots of people were trying to fix the DOM in the open source space when jQuery come about. The factor that contributed to jQuery’s success was [John Resig’s](http://ejohn.org/) personality, the people attracted to this personality, and its trickle down effect in the community as everyone worked together for the good of the community. What I learned is not that complicated. Success is tied to relationships and how people are treated. A high moral standard and a general kindness/respect towards others regardless of intelligence or knowledge is the chief corner stone in successful open source efforts.
**Q: ThickBox has been status quo since 2007 and I know that projects becoming unsupported or abandoned is a common concern/complaint in the open source community. What were the deciding factors that led you to stop working on this project, how did it affect existing users and how did you respond to the community?**
As previously mentioned, I was dragged into a supporting role for Thickbox. I didn’t set it up to be used and supported. I created it to showcase jQuery. To that end, I believe it succeeded if Thickbox success and it’s intertwined rise with jQuery can be used as the measure of success.
At first, I made an effort to keep up with the emails and the phone calls. I even created a forum so the community could help itself, but at a certain point it was more than I could keep up with. It started affecting my day job, personal life, and mental health. At that point I withdrew, retreated, and rested. The experience was so severe for me that I missed the first jQuery Meetup and was conflicted about my desire to participate in the community at all.
Looking back, it’s clear to me that I never wanted to create or manage a Thickbox community and for this reason I stopped supporting Thickbox. Eventually my efforts went to the jQuery community, which is why I created Thickbox in the first place. I suppose one could say I wanted to support jQuery, not Thickbox and, thus, my actions reflected this.
How did this affect the users of Thickbox? To be honest, I have no idea. Eventually I know people started using other solutions and Paul Irish requested that I update the website recommending other, better, solutions. By the time I stopped attempting to support it, legitimately better solutions (code and functionality) were available and my response to the community was use the best solution available that solves your problem.
In general, very few people truly understand how widespread the use of Thickbox became and its intertwined relationship with jQuery. It was dumbfounding how many sites were using it. A single individual supporting it was never realistic and certainly creating an organized community/team around a single solution like Thickbox was a wasted effort given the problems of the day.
My books are different in four ways. Each of which you’ll either love or absolutely hate (if you don’t believe me, go read the reviews on amazon)
1. I’m repetitively hitting on the same concepts over and over because we know that repetition, while annoying, works.
2. I write code heavy books which reinforces my belief that code should be primary and words secondary. I write attempting to lure the reader into being a code leaner, so that its the code that teaches, not my words. I do this so that all code will become a resource for learning.
3. I write as if I was the reader. Now a lot of people say they consider their audience when writing but I go above and beyond trying to get into the heads of my readers. Trying to meet them wherever they are. In fact, the best compliments I’ve been given on my books is that many readers feel like I was learning for the first time with them as I wrote the book. Which is exactly what I set out to do. My desire to meet the reader where they're at is a reaction to the mountains of technical books that I have read that are either a mile wide and an inch deep or so elitist and narrow only a small percent of developers can easily learn from what the author is talking about.
4. I systematically break down big things into small and concise concepts each backed by runnable and heavily commented code. It’s actually harder than it sounds, and certainly this style has its critics.
Why should the community bother reading these books? I’m not sure the community as a whole should read these books. [Andrew Dupont](https://twitter.com/andrewdupont) taught me one of the most important lesson I’ve taken from the web developer community. And that is, not everyone’s brain works the same and working from a premise that is does, or should, is highly problematic if not a fallacy. He asserts that we should find what works for our brains and do that. So, **should you read** my books? I don’t think **you “should”**. However, if you start reading it, and it helps your brain learn more about something you want to know more about then yes, you should read it. If not, discard my book and find something that helps.
**Q: Your books are obviously meant to be a teaching mechanism which leads to the next question. With new tools being released almost daily, how do you keep up with the ever-changing client-side landscape of libs and tools? What’s your thought process for choosing the ones you think are important?**
I do not own my own company or belong to the small club of highly skilled and intelligent developers that get the kind of jobs that permit them to dictate their own career endeavors. So, more often than not, what is important and what I focus on is whatever someone is willing to pay me or the company I work for to focus on. Someday I hope to choose the problems I want to solve and in turn the solutions I focus on but until then I am a solution person assigned problems.
The question of keeping up gets asked a lot. My canned response is as follows.
Keeping up with front-end technologies is daily task. As part of my daily activities, I spend 20 to 30 minutes reviewing twitter and RSS feeds, investigating anything that sparks my interest. I am also regularly reading (books), watching (videos), or writing about my practice. From time to time I pick a coding, or writing project and focus all of my spare time in this area. When I tire of writing words or code I simply spend time reading code. When I'm feeling burnt out I'll attend a conference so that I can be inspired by ideas and people. And when I am really bored I start looking into practices that cross over into my area of expertise. The secret to keeping up is not to view it as an extra chore, but instead as part of the job I've chosen.
I suppose my canned response is adequate, but even more pragmatic than my thoughts on the topic is the fact that keeping up boils down to making the time, staying dedicated, and doing the hard work of learning. No shortcuts or secrets. Get in the trenches and do the work of learning, thats how you keep up.
**Q: I see this constant influx of new tools as a natural formalization of processes and methods in web development but in many cases, it equally feels like there’s ego involved (i.e.: look what I built). Are all these new tools helping or are they actually leading to greater confusion and tools fragmentation?**
As long as a human is involved, someone’s ego will be involved. Just no way around that. That’s all I have to say about that.
As for the flux of new tools, surely the innovation, egos and good created by an abundance of solutions outweighs any confusion or fragmentation that might occur. I’m an advocate of what many people call fragmentation simply because it means different brains, with different voices, are trying to solve the same problems. If everyone’s brain worked the same way then a large mass of innovation solving the same problems would not be required. Fact is, innovation comes from lots of different people solving similar problems in unique ways. Standing at the sidelines complaining about this fact is pointless. Developers working on the web platform just need to accept the fact that they will continually be swimming out to the wave, trying to catch the wave, and accept that on a regularly basis this will be done on a new surfboard.
I often come across this same fallacious thinking in the context of authoring suggesting confusion and fragmentation caused by duplicated efforts. That’s silly. All around us are examples of people doing the same thing with a unique perspective. There is always room for someone new, to say or do something old or common, in their own unique way. If degrees of re-inventing the wheel stagnates, I believe learning will also stagnate.
**Q: Which leads to another concern: “Do you need to be a full-stack developer to be successful?” You look at job descriptions & it’s starting to seem that if you don’t know how to code for the whole stack, you might be left behind. Is it still possible to focus on a specific area, like client-side development, and still be on a good career path?**
A lot of this depends upon the employer and the job. Being a full-stack engineer (and certainly node is making this easier) at a startup or on a weekend pet project is certainly viable. However, the runway on being a full-stack engineer is small. Eventually a human will have to remain focused on one logical and related groupings of thought in order to excel at it (i.e. have useful experience that results in the solving of hard problems). Contextual switches have been the enemy of progress in every software engineering endeavor I participated on, so moving from say database design to CSS is just not a reasonable switch for humans.
Now, to generalize, I would say that the idea of a full-stack engineer or what we used to call a webmaster is in general not practical. Don’t get me wrong, I know of a few exceptions to this but nobody should form a hiring strategy thinking they can hire a team of rare and exceptional developers that defy the common thresholds of learning most humans are equipped with. The average person has an average threshold for what they can learn indepthly and full-stack engineers are anything but average or above average.
**Q: Along these same lines, I’ve seen a lot of developers bank their future on jQuery. What are your thoughts on that? Is this a smart move considering the trends towards single-page apps?**
I don’t see the direct (sprinkled in a web page) or indirect (i.e. dependency) use of jQuery going away anytime soon. With that said, banking on one specific technology being around in the future given the history of our profession seems problematic.
This question reminds me of a [speech that Lauryn Hill](http://youtu.be/e5vqmHXnT70?t=7m) gave to a group of young adults in which she exposed the reality that if you are at the top the only place to go from there is down. If that is understood, I think developers can intelligently ride the present top solutions to their logical end and bail when it makes sense.
**Q: Speaking of SPAs, where are you personally looking at (Ember.js, AngularJS, Backbone, Knockout.js, etc.) and why?**
After reading this interview, I think you’ll see how my description fits Cody and in my opinion, I love that he forces you to rethink your preconceived notions about things. He and I have had long conversations about technology and life and I feel fortunate to be able to bring his insight into development, technology and life to you guys.