Tip:
Highlight text to annotate it
X
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 ***, 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.