Co-founder and CTO of Quick Left, Sam Breed sits down with me to discuss how to control code debt, how he chooses which technology to work with, and which not to, and how speaking at conferences can be an excellent way to get out in the community and meet future clients and hires.

Sam Co-Founded Quick Left in 2009 with Ingrid Alongi as a service based company focusing on providing excellent service to funded startups. As of January 28th, Quick Left merged with Sprintly, adding a SaaS management platform product for software development to their service-based business and added two new locations in Portland and San Francisco. After touring us around their green nature inspired office in the center of Boulder, Colorado, just off of Pearl Street, we sat down to talk about how Sam’s journey developer to CTO, and how he keeps Quick Left on top of the latest technologies.

You can find more information about Sam Breed and Quick Left by visiting their blog, and following them on Facebook and Twitter.

Video Transcript

Brent: I’m Brent Weaver, and you’re watching uGurus, the must-watch web series to become a more profitable and in-demand web professional. Today, I’m in Boulder, Colorado, with Quick Left’s CTO and cofounder, Sam Breed. Welcome to the program.

Sam: How are you doing?

Brent: Sam, what’s your background?

Sam: I’ve been doing web development pretty much since I was 10 years old. I started with Geocities and Angelfire pages in the late ’90s and then stopped for a while. I actually moved out here to Colorado to go to film school at CU.

After a couple years of that, I dropped out and from there, started freelancing, doing freelance web development — WordPress, web design, PHP development — and then ultimately got into doing JavaScript dev. That’s when I came onto Quick Left in early 2009.

Brent: So freelancer to CTO.

Sam: Yeah, that happened over the course of a couple years. You know, I was early in on the ground floor at Quick Left. There was one other guy, Colin, at the time, and he hired me on as, essentially, an apprentice developer doing PHP dev and JavaScript and CSS.

After about six months of that, we knew Ingrid socially, and Gnip laid off a whole bunch of people. We brought Ingrid onto the team, and from there, it really started changing into less of a couple of guys in a room slamming out websites as fast as we can for not nearly enough money to something where we started hiring people, and we got a bigger office.

Over the course of the past five years, I’ve gone from being a developer to running projects to running a couple projects at a time to my role now, which is CTO, which involves a lot of outward-facing evangelism. I work on open source. I speak at conferences. I still help run the dev team but from a much more 30,000-foot, strategic point of view.

Brent: Talk to me a little bit about doing conferences and outward evangelism. What kind of stuff do you guys do?

Sam: We absolutely love conferences. I started going way back in 2008, 2009. I started going to JavaScript conferences and then to handful of Ruby conferences, as well.

When I started going to these things, I learned so much and found this awesome community that was coalescing around open source projects. These are guys that hang out in IRC, that are talking on Twitter, and there is a really big community that’s outside of just the local sphere that you might be into, even if it’s as great of a town as Boulder.

So after just going as an attendee and really liking it, I started getting more interested in speaking. I started speaking at conferences, and we have a handful of other developers that have picked up that lead. Last year, we had Alex go to Russia to speak at a jQuery conference. I spoke in Portland and was down in Austin, Texas, as well. I ran trainings in San Francisco.

It’s something that is really attainable. You just have to have the desire to want to do it and put your research in and pick good topics. Public speaking is easy once you’ve done it a couple of times.

Brent: How do you actually get to be a speaker on a technical level? Are you just emailing people? Are they emailing you like, “Come, Sam, speak at our conference?”

Sam: No, no, not quite at that level. You know, the main thing is recognizing what good content might be. It can’t be too technical. It can’t be too dry. It can’t be too airy and fluffy.

I like speaking at a broader level of, “These are things that you can do to help make your development practices better, to help work better with your team,” as well as doing some deeper dive technical stuff that’s really more specifically JavaScript.

To get accepted at conferences, you just have to submit to them. All conferences will have open submissions, and most of them, if you email with the organizers, they’ll give you feedback if you weren’t accepted for one reason or another. You don’t have to be afraid of not submitting the same talk to multiple conferences. That’s how you get in.

Then, once you’ve spoken at a couple, especially if you start with regional conferences or Meetup groups, it’s a lot more likely that you’ll be invited to speak again. Then, hopefully, you can get to the point where you’re getting invited to speak at places.

Yeah, it’s a lot of fun and a really good way to get out there in the community, meet new people, meet people that could be future employees or future clients. When you pay it forward and try to give back to the community, in my experience, you always get that back down the road.

Brent: Now, as a CTO, I assume you have some hand in what technologies Quick Left uses and what technologies you don’t use. There is a lot of stuff out there. How do you evaluate that? How do you make those types of decisions?

Sam: Well, Quick Left has a handful of technologies that are right in our back pocket that we use all the time — JavaScript, Backbone.js, jQuery, and on the Ruby side of things, Ruby On Rails and a handful of gems — that you know are kind of common between each project.

Our policy for taking on new projects and new technologies for those projects is really one of personal ownership and dedication. If you have something that is a good fit for the problem and that you’re willing to own and stay up with if it needs some love, there is really no problem with bringing that into the fold. Obviously, we hedge our bets, and we definitely have rejected technology suggestions, but we really try to evaluate things for their own merit and on a case-by-case basis.

We were a PHP shop at one point. We became a Ruby shop. Then we started taking on more and more JavaScript work, and now, especially after the merger with Sprint.ly, we’ve got a really, really diverse team, so our coverage includes Python and DevOps and doing some really tough scaling problems. It’s hard to get that type of experience, and to have that on the team now is really feeling like it’s pretty special.

Brent: Has there been any really cool project that you’ve gotten to work on? Are you still working on projects? Do you have your hands in code?

Sam: Oh, yeah.

Brent: Or are you . . . okay.

Sam: Yeah, I write code every day. One of the things that I do as CTO is a lot of on-site consulting with companies that already have a lot of technology in play, and they have started assembling code debt. We’re really coming to a time where a lot of that is in JavaScript, and I’ve had a lot of experience helping people fix that and helping them turn away from the things that are over-architected.

The relationship with Sprint.ly actually started with me being brought in to help fix JavaScript on their application. I still work on that product every day. The only difference now is that it’s a product that Quick Left owns.

It’s been really fantastic working with the Sprint.ly team and getting to know how they do product and what goes into their decision making. It’s been really fun to help along the way with some of the really tough problems that manifest themselves when you build an awesome product and iterate and run really fast and add new features and add new people to your team.

But I still code every day.

Brent: You mentioned the term “code debt.” This is a term I’m actually familiar with. My CTO actually gave me a full-on presentation on code debt and what that means and all that kind of stuff. Can you give us a brief overview of code debt?

Sam: Yeah, basically, there’s this notion of software entropy. The natural state of software is to be completely broken and untested and unreliable. It’s funny because it’s human beings behind any line of code that’s written, and there are very few of us that write bug-free code. In fact, almost none. I’ve never met one.

When that happens once, it’s okay, but when it happens over the course of a very long time when you’re goals are shifting and your priorities are changing week-to-week and you’re iterating, it’s very easy to start ignoring the things that you might not like. It’s like how you get junk drawers in your house. That’s essentially what code debt is.

It’s difficult to recognize that over time. It creeps into software projects, and while there are definite ways and means of keeping those types of things out of your projects, sometimes you just need somebody to come in from an outside perspective and go, “No. This isn’t scalable anymore, and here’s why.”

It could be at an architectural level. It could even be on a very basic syntax level, like mixed tabs and spaces in a file. It’s like an indicator. A big red light flashes, and it’s like, “Man, you’ve got to care about this stuff.”

So it comes of . . . people are lazy, and the best programmers are actually extremely lazy. So it’s something that just naturally occurs over time that builds up in projects.

Brent: Sam, have you ever had a project that just totally went off the rails, so to speak, and kind of crashed and burned, something that isn’t, maybe, a highlight of your career but you’re willing to talk to us about?

Sam: Oh, yeah. We’ve definitely had some interesting projects. Projects can get really dynamic sometimes, and it’s always our job to try to pitch solutions even in the face of . . .

I think that probably one notable case is we were working with a startup here in town that was basing their whole premise off of massing a database of contact data for politicians. This exists out in the world, but you have to pay for it.

Essentially, we had done all of this planning, and it started a couple months into this project, and the source of data that they had negotiated with and paid for had worked its way into very many places in the project. The planning perspective essentially disappeared, and we were left with not a whole lot of time left in the project.

We had to really think hard and lock ourselves in a conference room and figure out what the alternative sources were, what we could pitch, how we could essentially make good on the money that our client had invested.

That was probably one of the more extreme cases, but things like that happen all the time. I always say in sales meetings that your expectations on day 100 are usually going to be miles away from your expectations on day zero when you’re planning the project.

One of the reasons why we really focus on building minimum viable products for people is because over the course of six months, you may have to pivot three or four times. So if you spend all of your time building a cathedral and then ripping off the curtain, you’re probably not going to like what’s underneath there, and your customers might not like it.

So releasing early, releasing often, soliciting customer feedback, and really treating these problems, these sociological problems, of, “Is a user going to want to use this? Are they going to want to engage with this? Does this product have legs?” treating those as scientifically as possible and cordoning things off into small sections so you can actually do something and then measure it a little bit, that’s really what is the turnkey for success of any type of project.

We won’t necessarily guarantee you a success, but hopefully, we can make you fail fast if you’re going to fail at all.

Brent: So you’ve got a lot of problem solving in your job. How do you stay sane? Is there any daily practice or habit that you keep?

Sam: You know, I really like . . . I ride my bike to work every day. I skateboard most days when I can. It’s snowing today, so I don’t . . .

Brent: There is definitely some snow outside.

Sam: Yeah, I don’t think it’s in the cards today. But I really enjoy coming to work, and I really enjoy interfacing with everybody else that’s around me.

When I’m not at work, I do a lot of work on open source, I watch a lot of movies, and those types of things keep me sane. The standing desk at work definitely helps, too. I banished my chair into the land of wind and ghosts about eight months ago.

Brent: How long did that take to adjust?

Sam: It took about a month. Now it’s like when I go off-site to people’s offices and they don’t have standing desks, I usually make the suggestion that they get one because sitting literally kills you when you do it for eight to ten to twelve hours a day. That’s one of the things that have definitely helped in terms of practices at work that, over time, make you feel better.

Brent: Very cool. What are you best at in terms of what you do at Quick Left?

Sam: I’m really good at getting excited about solving problems, about tackling new challenges, and about implementing projects. I feel like one of my roles is to be cheerleader for the consulting practice and now the new products that we’re bringing into the fold. Sprint.ly, hopefully, is just the first of many Quick Left products that we’ll see over the next few years.
I really enjoy helping people solve problems, and I think that when it comes to code, I’m specifically pretty good at a few things, and it’s just amazing to be able to feed off the energy of all the great developers and the rest of the staff here to really make awesome software for people. I’m good at that.

Brent: Very nice. What trends are you following right now?

Sam: One trend that I’m definitely interested in is DevOps. Essentially, that is the new kind of buzzword that is associated with being able to deploy things and manage large infrastructures automatically.

It used to be that 10, 15 years ago, servers had to be physically configured and racked and turned on and plugged in and then set up very carefully. Over the past couple of years, though, with everything moving to the cloud, everything on platforms as a service like Heroku or on your own manual infrastructure that you set up in AWS or Open Stack or something like that, there has been a renaissance in the kind of tooling.

The same software principles and practices that you can apply to application development like we do — test-driven development, really sophisticated ORMs, stuff that we get in Ruby On Rails, and then all of the cool stuff that we have in JavaScript — those same tools and techniques are moving into the DevOps space, so you can actually write tests for the infrastructure before you deploy it.

So it’s moving from this thing that was very left to the neckbeards in the room and the guys that took wearing pagers as a badge of honor because they had to go and hot swap hard drives and they died in servers and shit, that’s being democratized to the point where full stack developers were able to do it. It’s something that we offer as a consulting service now. So that, in particular, is one.

I think of all the modern language development that’s been going on. JavaScript is definitely something that’s close to my heart. It’s something that I spend a lot of time with. The next version of JavaScript, ES6, is getting drafted now. That’s going to continue the trend of the past couple years of really bringing rich, smart features that don’t break the internet. There are things that you can do with JavaScript that if you changed, the whole internet will not work the same and things won’t get adopted. There’s a lot of really fun development going on there that I’ve been tracking closely.

And then even new languages. Go is one that we’re particularly excited about here. That’s a language out of Google that is cherry-picking the best of the best kinds of concepts and techniques from a lot of other places. That’s been fun to watch, too.

Brent: What’s your next move in terms of this Sprint.ly merger? That’s got to be taking a lot of your headspace right now as a CTO?

Sam: Yeah, that was something that spent a while in the oven. Joe and I have worked really closely together over the past year or so, first, when I started working on the Sprint.ly project, and then we had a consulting engagement in the U.K. that he actually recommended me for that he had been doing for a couple years.

We spent a lot of time together and built up a lot of planning and had been kicking around a lot of ideas, so to finally have all of this happen and be able to announce it to the world, we’re just overwhelmingly excited to start working on the next stuff.

Right now, I’m working on Sprint.ly to try to make it as awesome of a platform for helping developers and their managers because they’re my customers now, too.

Brent: Very cool. Well, best of luck to you on that project.

Sam: Yeah, thanks a lot.

Brent: And best of luck to you at Quick Left.

Sam: Okay, awesome.

Brent: Well, Sam, I appreciate your time today. Stay tuned for more great content from uGurus.com.