You have built "the framework for web artisans" with an emphasis on clean PHP code and fluent syntax. Why did you choose this expression to describe the framework?
In the dictionary artisan is just a synonym for craftsman. So a "web artisan" is basically someone who is just passionate about web applications; passionate about coding. They probably code in their free time. Sort of like a hobby for them. Their code is something they are passionate about and they want to provide a good product. I carry that quality through all of Laravel to make it a polished product. I put a lot of time into it. All the way down to the presentation of the documentation and supplementary tools like Homestead – having the whole experience be really good is important.
The tagline was just a fun little way to say that this is a web framework that might appeal to you if you are someone who is passionate about high-quality web applications.
Do you think that describing it as "artisan" is a bit pretentious? What do people think of this qualifier?
It was not meant to be pretentious or exclusive. At the end of the day it was marketing and meant to be fun and to say "Hey if you are passionate about the web, we are too. Let's be friends." It has always been a little funny to me that people make fun of "artisan" but they also use the word "craftsman", which is literally the same thing. It is not meant to be "we are artisan and you are not" or anything like that. There was never that much thought that went into it. It was just a tagline that struck me as I was first building the framework. I love doing web stuff and tinkering with stuff. The idea that "artisan" fit building products that really help people was the whole motivation behind it.
You just said that you build products to help people. We like that idea as we associate the value of a product with the meaningfulness it has to other people. So do you see "artisan" as having an empathetic quality about it?
A lot of the stuff I build is to help developers. It is to help make their work better and, in turn, they turn around and make various other people's lives better. Even before I built Laravel, when I was working in .Net, I actually built .Net dev tools within our company. One such tool was like a Slack before there was Slack where you could share files, chat and collaborate with your team. But I have always enjoyed streamlining developer productivity. I guess because as a developer I see little details that take time and annoy me and I think, "wouldn't it be great if I could eliminate that, or make it automated." I just enjoy doing that and shipping it out to other people.
How did you progress from your first days of coding to where you are now?
I have an interesting story where I actually graduated from Arkansas Tech with a bachelor’s in IT. That major was more computer networking and hardwiring stuff. I only took two semesters of C++ and then one database administration course. I had no plans of becoming a programmer. Even in my senior year of university, this is not what I expected to do. I expected to be a network admin or something like that.
But there was a company in Arkansas that hired me to be a programmer. They had a program where you came in and were in training for six months and would be trained how to do .Net. So how I grew as a programmer was through that training, but even more than that the people that were on my team were all way smarter than me. I had only had two programming courses up to that point, so they actually helped me grow the fastest because they had great training.
At different times throughout your career, have you had employers or coworkers who were directly responsible for ensuring you got to the next level? Were you ever an apprentice to an artisan?
I was lucky because within that organization my 3-4-person team was people that were more than just day programmers. They were really passionate about programming as a craft. I did not know what an interface or an abstract class or anything like that was. They took me under their wing and helped me learn a lot faster than I would have on my own. I could just walk over to their cube and chat with them about different programming concepts. We would draw on a whiteboard together and it was a much better way of learning.
How important was that experience to you?
That initial team that I had has been the most helpful experience. Not only did they teach me a lot, but they also sparked excitement about programming because they liked to hack on fun little side projects and opened that whole world to me. I had never heard of open source and they showed me that. The team aspect and collaboration helped the most.
Do you think this a common scenario or career path for others? Would you encourage others to try it?
I have only really worked a few jobs before I did Laravel, so I do not know how common it is. I hope it is common because it was really beneficial to me. I would definitely recommend it to anyone, just knowing how well it worked for me. You can be around people who are smarter than you, no matter what level you are. There is always going to be someone [who is so smart] that it makes you feel stupid. That is the way to learn the fastest I think because you can ask that person questions and they can explain concepts to you. In a way, I think that is a lot better than researching on your own because they can see where you are struggling and they can help you get back on the right track.
Do you think Laravel and its community has enriched the learning path for would-be web artisans?
I think the point of the framework is really more to help you build your projects faster. I think learning good practices and stuff comes mainly from community members sharing knowledge through blog posts. The best practices for using Laravel may change over time so they are not really statically documented somewhere in the documentation. I think community members like Jeffrey Way and Matt Stauffer who write a lot of articles and record Laracasts are the people more in a direct mentoring role than I am at times. They are the ones that can set the trend for helping people grow and establishing best practices.
You know the Rethinking Loops talk by John Kary that we just came out of was essentially showcasing the use cases for collections. Adam Wathan is writing a book on Laravel's Collections and how to use them to improve your code in a lot of the same ways we just saw John demonstrate. Things that emerge from the community are what guide people towards best practices. What is important for me is having an environment and a community where people are inspired to share that kind of work. How do I create an environment where Adam feels passionate enough to write a book about it? Or that Jeffrey feels passionate enough to make videos about it? From the very beginning, I wanted to have this fun, inclusive environment where people enjoyed being around each other and that makes people want to contribute and evangelize the whole idea.
Do you think people still see you as the only leader in the Laravel community even with so many others who are more vocal and more directly connected to the developers than you?
I feel like the tools and myself as the creator have become somewhat intertwined over the years, where Laravel and Taylor have become synonymous in many people's minds. They are not. I try not to make them so dependent. I try to always, whenever talking about Laravel, say "we are doing this". I try to never say "I am doing something." I try to always deflect the credit and make it seem like a community even though I am the main contributor and merger of the actual code and projects. I do not want people to feel that Taylor is unreachable. I want it to feel like a collaborative group.
You are now sort of a one-man company building holistic developer tools. You are clearly a talented programmer but what is your approach to business?
For me, it has always been me trying to scratch my own itch. Most of the time, everything I've built – Laravel, Lumen, Homestead, Forge, Envoyer, and now Spark – are all the real challenges that I had to solve and I did not have a good way to solve them at the time. With the for-profit tools like Forge, I felt like I was always having to spin up servers and configure them, and Google how to set up SSLs, and Google how to clone jobs and all that stuff. I was just tired of doing that. It felt so natural that even if I built this, and no one else used it, I would still feel good about it because I would never have to configure servers again. That is what I told my wife when I was building it, "even if I never make a single dollar off of this, it is going to save me a lot of time." I think just scratching my own itch has really been my personal approach.
Do you think that the challenges you face are same real-world problems that, say, an engineer at a large, sprawling enterprise might experience?
I never try to build anything that I do not personally have a problem with. I simply cannot relate to it. I do not know how to solve it in a meaningful way without either having experienced myself or having someone that is right there with me that has the problem.
How do you know what business challenges need solving versus those that do not?
Now that the Laravel community has gotten larger, I have to listen to people and take contribution where I have not personally encountered their situation. That has happened frequently as of late, especially on the Validator components of Laravel, where people have advanced validation scenarios that I have never had (and never want to have). I can at least put myself in their shoes, and can conceive a solution that is feasible for their situation. It is also helpful to look at other frameworks. What are they including? What is Rails including? What is Symphony including? That kind of broadens my scope too to say, "is this a legitimate framework feature?" or maybe "should I create a package or something for that?"
Do you have a particular sized company or group of developers in mind when you build features for Laravel? Are you listening to any particularly vocal people or influencers in the community to, for example, adopt more enterprise features or make things more accessible to beginners?
I do not intentionally try to listen to a certain group of businesses. Lately, it seems to be small developer shops. I do sometimes have larger companies contact me but it just seems for some reason that mostly it has been smaller companies, smaller dev shops. It may be that Laravel is still young in terms of the other frameworks like Zen and Symphony, and only now after a few years is it getting into bigger companies, where you see people like Apple posting job listings for people with Laravel experience and universities teaching Laravel in web development courses. It took a few years to get to this point, so it may take a few more years before we start seeing a shift towards bigger and bigger companies reaching out.
Artisans Collaborative has been fortunate to work with enterprises that are adopting Laravel and modern PHP best practices. We hear some backlash from those in the PHP community who challenge Laravel's technical utility in this landscape. We have come across a few business cases where Laravel was not the right fit, but never a serious technical limitation of the framework. Do you have any technical reason why Laravel would be a bad choice for companies looking to switch from another PHP framework or no framework at all?
I do not think so. I think the ironic point about challengers to Laravel's use in the enterprise space is that Laravel has a lot more enterprise features than some other frameworks. Many of those who argue against Laravel have never actually used the framework. That's one reason I try not to comment on other frameworks because I've never really used them. If I meet someone who bashes Laravel at a developer conference, and I can sit down show them Laravel and what the dependency injection container can do, what the queue system can do out of the box, what the event broadcasting can do with real time pushing, then a lot of times what people think they know about Laravel is not what Laravel actually is. So much of what they hear is a small but vocal crowd on social media. If people give it a fair shot, I think that they will see it is just as capable of any of the other popular full-stack frameworks. Not to mention there is Lumen for those needing a micro-service framework and the individual Illuminate packages for those who just need components.
Artisans Collaborative is encouraging companies to take a more active role in educating their teams by pairing apprentices with artisans to kick-start a new generation of more competent programmers, problem solvers, and, well, artisans. What do you think of this idea? Do you think there is a need for such a practice within the industry?
The whole apprentice to artisan approach has been so beneficial in my own experience that I have to say it is definitely something I would recommend because that is how I personally grew so much. There was never a formal apprentice relationship, but functionally that is what it was. I was with team members that were a lot more experienced than me and knew a lot more than I did. They were able to guide me. I think that is a model that obviously has been proven throughout the centuries for certain crafts and I think applying it to programming makes a lot of sense. Programming is just another craft that you can learn and master. You can always be mastering it throughout your life.
One challenge we have encountered while trying to get companies to foster a formal apprenticeship program is the desire to embrace remote working. We love remote working environments and most of our team telecommutes, however, all our employees are Texas-based and most all contractors are living in the United States. This does not work for some companies whose employees are spread out, but that is our current solution for this modern workplace challenge. What do you see as a workaround for gaining the full apprenticeship experience within the modern workplace?
All the modern benefits of remote working and telecommuting, while great, do pose a communication barrier that hampers the relationship a bit. There is just something about being in person that is hard to replicate on-line. When you can just be in a room with a whiteboard and your laptop sitting next to each other, collaboration seems a lot easier. I think that technology like Sreenhero and Slack try to recreate that environment but I do not think it fully recreates that face-to-face, in-person interaction.
Telecommuting is becoming more and more popular, so I think as remote working becomes more and more popular that the benefits of remote working may outweigh the value of personal interactions to many businesses. Special attention should be paid to make sure that if you find yourself in one of those companies that you find a friend or a mentor to collaborate with in person as well. Join user groups, go to developer conferences and try to find someone from your local area. Lone Star PHP is the regionally closest conference to me, which is one major reason why I am here.
Who do you think are the biggest advocates and thought leaders within the industry who are promoting the model?
Yitzchok Willroth (@coderabbi) for sure. His whole campaign for the last year was, "get out there, find a mentor." He also encourages people to be a mentor if they are in that position. He encouraged people to be involved in the community. We had him present at Laracon 2015 because we felt it so important for the Laravel community. There is also PHPMentoring.com and other people like Anthony Ferrera who talk a lot about mentoring.
You attended Lonestar PHP as just another programmer, which is different for you since you run a conference of your own and speak around the country. Clearly you wanted to learn something new too. So what were you trying to get out of the conference?
I came to relax and meet other programmers. I wanted to hear what they are building and hear about the problems they are having because that helps me as a tool builder and framework maintainer. They might mention something offhand, "you know we struggle with this" or "we are working on that" I tuck that away and try to remember it the next time I sit down to build something. I also find it important not to be the smartest person in the room, so I like to surround myself with people who know more about various topics than I do.
I heard a lot about Docker and in the next few months, I am just going to play with that and see what that experience is like. As I go around to different conferences, hearing what people are struggling with, hearing what is frustrating them as developers sort of gives me ideas to tinker with.
When you are learning something, do you try to work with it yourself first or do you just build on the work of the subject matter experts?
I do like to try to do it by myself because that gives me a good feel for what is the experience of the beginner. Continuing with Docker, for example, coming into Docker as a total beginner just starting to work with it helps me see all the things that I struggle with. If I struggle with it then probably others are going to struggle with it too. Then I work out the pain points and make it a better experience from beginning to end. That's what it's been like with Homestead, Forge, and Envoyer. Just me trying to make it easier from start to finish.
What skills are you actively trying to improve upon for yourself? What are you finding that is hard to learn?
It has been hard trying to know when to delegate certain things or how to divide up the work, when to know how to hire someone to work on something part time or full time. When you work on something that you're passionate about, it is hard to let go of that and let someone else work on it. You worry that they will not be as passionate about it. But obviously, that is what you have to do eventually because you just do not have enough time. So just learning to let go and to practice the soft skills of software development. It is more of a struggle with the business aspect of things.
Do you use Laracon to specifically address these types of concerns you have about the craft? Are you working at making both these beginner and expert level experiences part of the conference spotlight?
I would love to see us do multiple tracks at Laracon, where you have an even more technical track and then also a business development track for people who are programmers but who may own their own businesses and want to learn how to develop those skills. I think it would be great for pure business people who are not even programmers at all too. I think those sort of tracks are really needed at Laracon because you have this framework built around the whole premise that it helps you launch businesses faster. That is why I wrote it. With Spark now out, it is needed even more. So having those kind of holistic developer talks at Laracon and other conferences is very natural, because entrepreneurs are what I want people to be.
There seems to be a mindset among many talented programmers that what they have to share is not seen as important or advanced enough for conference tracks. The so-called "imposter syndrome." Some only present at user groups for fear of not having talks that are relevant to larger audiences. What advice do you give to these would-be speakers?
I think talks on the transition between programmer and manager are super relevant. I think these talks are needed because a lot of people are just winging it. Many dev shops are so busy that they never really sit down to figure their processes out. If you know how to do something, come share it with others. There is going to be a significant number of people in the room who did not know it. I think that if there are those who already know it, there is at least something you can contribute to spark the discussion.
With all the products, releases, conferences, and things you do for the community on a daily basis and the incessant drive to make it better, do you struggle with the pressure to one-up yourself?
Yes. Lately, it has been Spark and being ultra perfectionist about the code. I've been working on Spark for almost a year now. This is the first time I have struggled this much to get something out whereas with Forge and Envoyer, I built them over the course of a few months and they were out.
I think because it is the first time since I have shipped Laravel that people are going to have a significant amount of my code in their hands, in terms of how I would use Laravel. It showcases how I would do my controllers, how I do my validation and all of that. I am trying to write it in a way where it will be good enough for people to look at and enjoy as a learning experience, but also something that they can trust. This is going to be the foundation of their start-up idea. I would want to know that my foundation is solid and not have to worry about it questions like, "is this going to work for me?" So I am trying to make sure it is perfect to the core and that has taken a lot of time.
I think maybe I have stretched out the launch a little too long and that has been a struggle for me. I need to learn when to say, "OK, this is done" and not just sit staring at my screen for another hour refactoring one method. That has not been a struggle for me in the past. It has sort of been the opposite in the past where I'll hack something out, spike it out real fast, and just get it out there. So this has sort of been a new struggle. Now that I have launched Spark, the pressure is on for the next thing to show at Laracon. At the same time, I try not to think about it too much. I am only one person and I will see where things go.
I would like to take a moment, on behalf of everyone at Artisans Collaborative to thank Taylor Otwell for taking the time to give us such an in-depth interview into his personal career and developer struggles. Taylor is an all around nice and humble guy who just wants to make better tools for others. His passion for quality craftsmanship and his inspiring work with Laravel and the surrounding community speaks to us. The motivations behind his relentless pursuit of quality align with our vision for the next generation of artisans and are the primary reason why we enjoy working with Taylor's tools every day. It is because of people like him that we are able to do our most creative work every day. We all owe Taylor a huge debt for his contributions to making developer's lives and the lives of their customers better.