Building Infinite Red

Connect with the owners on Twitter!

• Todd Werth: @twerth

• Jamon Holmgren: @jamonholmgren

• Gant Laborde: @gantlaborde

In this episode of Building Infinite Red, we talk about the importance of education and experience when starting out in software development and how things change when you move from making your products to running your business. From books and online resources to bootcamps and higher education programs, Jamon, Ken, and Todd share their stories, insights, and opinions for every level of professional.

Show Links & Resources

• Lambda School
• Austin Allred on Twitter
• Epicodus
• Airtable

Episode Transcript

TODD WERTH: Today's topic is education. I actually don't recall what this topic's about. Ken, do you recall?

KEN MILLER: Yeah. Well, it's this question that kind of comes up periodically about developers and CS degrees and that kind of thing. I think there was a Twitter thread a little while back in Jamon's feed, because Jamon's feed is the only feed that matters.

TODD: That's a fact. Yeah.

KEN: Yeah, do you remember who that was, Jamon?

JAMON HOLMGREN: Yeah. The question was, "I have 10 years experience developing sites, but I have no formal education. What are your thoughts on experience versus education? Been thinking of getting a front end development tech degree from Treehouse, but I'm not sure if it's worth the time and money." Yeah. That is a question that does come up fairy regularly.

KEN: For that specific question, I think the answer is no, it's probably not worth it, right? If you have 10 years of experience, and you're going to go take basically a practical degree, don't bother.

JAMON: Right.

KEN: But there are definitely nice things about getting a real CS degree, but getting a job is not necessarily the best reason to do it.

JAMON: Right.

KEN: If that make sense.

TODD: I would totally agree with that. Well, just to start out, the three of us, Jamon nor I have finished college, nor do we have any CS degrees. I learned to program on my own when I was a child, probably started when I was 12. And then I started programming professionally when I was about 24, and then I learned basically on the job.

Ken went to Harvard and got a CS degree there. Jamon, you are similar to me, right?

JAMON: I was pretty similar to you, yeah.

TODD: Yeah. So what I usually tell people, A, now, when I'm hiring people and I'm not representative of everyone, so it's quite a bit different, I do a cursory glance of their resume, maybe. That's less relevant to me than what they can do.

In my opinion, developers is a portfolio job, which means the work you've done is hugely more important than any kind of education.

Now, obviously if you do have a CS degree, I do find people want CS degrees, they understand some concepts that you maybe don't use day-to-day, and when they do come up, they have a much better understanding of that. Sometimes it's easier to teach them new ideas, because they have the analogy in their mind already. So it's definitely worth it.

I would say, my short answer and I'd love to expand on this further in this podcast, but my short answer is you need to learn what you need to learn in order to produce work product, which means develop software, develop websites, develop apps. And everyone has a different way of learning. For some people, school is the best way. For me, school always bored the hell out of me to be honest, and it wasn't the best way for me, but there's no exact right way for everyone. It's just however it works best for you.

JAMON: Yeah. And I think that part of this is how much access and opportunity you have, because certainly college is one fairly proven path toward gaining an opportunity to access the job market, to get enough skills that you're hireable out of the gate, and then to access the job market and actually get a little bit of exposure, whether it's through an internship or something like that.

So that plays into this as well, if your dad was a software engineer or something, and he has contacts that you can talk to and maybe get some opportunities, then maybe you don't need that, maybe you don't need to go down that road.

But there are few other factors here as well. Some of them are personal goals, like what type of programming, like Todd was saying, what type of programming you want to do, how much debt you're willing to take on, how much you can take on. And then also, in some cases, very specific cases, the prestige of the university can be a factor because it certainl...

The theme of this episode is centered around the lessons learned in charging for software development. Starting with a question from the Infinite Red Community, Todd, Ken, and Jamon touch on hourly vs. project pricing, the tension between time and value, how software estimating is a lot like weather forecasting, and the many experiments conducted over the years to find the right pricing model for Infinite Red.

Episode Transcript

JAMON HOLMGREN: We received a question from the community, community.infinite.red, it's a Slack community that we have. Trent asks, "Hey Jamon, I'm enjoying the podcast. Will you guys be covering hourly pricing versus project pricing? It's a question we're dealing with right now. Which do you guys prefer, and what are some lessons learned to bring you to that choice?"

I think this is a really great question. Todd, do you wanna talk about what we're doing right now? And then we can go into maybe what we've done in the past, and what brought us to that choice?

TODD WERTH: Sounds good. Yeah that's a great question, and it's actually a really tough one to deal with. So, what we do now, is we do weekly pricing. We charge per person-week, and we call it "person-week" as opposed to "a week of work" because it could actually be two people working maybe half a week each and that would be one "person-week." Because we're doing person-weeks, we have a point system. So, 100 points equals a person-week. We don't track time. We used to, and we can talk about that—we used to bill hourly. We don't track time, we don't actually know how long things take, it's just, we estimate our tasks in points, and if we've reached a hundred or more per person-week and we charge per person-week, then we're accomplishing our goal.

JAMON: There's a bit of a tension between time and value, and this has been something that we've dealt with, I mean, I've dealt with, since I started my first consultancy. Of course, value-based pricing is kind of a holy grail of pricing for consultancies, and we've heard this for a long time, that you should charge for the value, not just the time that it takes. So an example, this would be fixed-bid pricing, where you're essentially betting on delivering the software in a reasonable amount of time, but you're getting paid on the value to the client.

The problem is that our costs are not based on value. So, we're not necessarily paying our people based on the fixed-bid, a percentage of the fixed-bid, or something like that. There are industries that do that, but ours is not one of them. So we're paying people salaries, and our costs are over time, and so if something takes a very long time, then our profitability and the ability of the company to remain financially solvent is threatened.

Conversely, you have, of course, hourly. We've done that in the past, and the nice thing about hourly is that it corresponds, obviously, very tightly with the amount of time that it takes to do. But the problem is that every hour is not equal. You have hours that are maybe really valuable, you've automated something and in a lot of cases you're actually delivering more value than the client is paying for, quite a bit more. And then there are others where the person's getting spun up, or they're hung up on a particular problem, whether it's their fault or not, and that turns into a bit of an issue, because then you're billing hundreds of dollars an hour for something where the client isn't really getting a lot of value. So I think that's why we ended up where we are, in a way.

TODD: Yeah, both have issues. When you're doing hourly, it might seem to a client that's more fair, but it's not. It means every time there's a bug, or any time there's an issue, we basically are nickel-and-dimeing them, and they don't necessarily like that. We have to spin up someone, like Jamon said, where in our value system that we use now, they don't see any of that. We fix the bugs because it's part of the value of that particular feature. It does mean, though, sometimes, that we can produce a feature faster than the hourly would've been, and so they get charged, I guess, more for that.

KEN MILLER: There's a couple of different ways that hourly works out sometimes, though. There's certainly the very literal, like, you sit there and you run a clock, like the way a lawyer would, you actually have a little timer that shows exactly what you're doing. When I worked for a large sort of corporate consulting company, Big Five-style, back in the '90s, I remember my first week I was filling out my time card, and I filled in the insane hours that I worked, because that's the kind of work that you do. And my project manager comes over to me and he's like, "No no no no no no no no, this is not what you do." And he took my time card and he ...

In this episode of Building Infinite Red, we are talking about clients and some of the assumptions that often need to be challenged when creating software. Throughout the episode, Todd, Ken, and Jamon touch on the importance of knowing who your audience is, what they value, and how your ideas will meet their needs.

Show Links

• Dropzones App Release by Mark Rickert
• A Dark Room by Amir Rajan
• Uncommon Sense by Derek Sivers

Episode Transcript

CHRIS MARTIN: Today we are talking about clients. It's an important topic and one that pretty much every business owner inevitably gets asked a variety of questions. The question that we could start with is: what's your favorite moment in working with clients?

JAMON HOLMGREN: You would think it would be when you launch their app or their site, or something like that, but I often find that actually to be a little bit anti-climactic 'cause there's so much going on. There's usually already plans in place for a version 1.1. It's not usually like everybody gather around the big green button and then the founder pushes the button, and it goes live. Although a little side note, Mark Rickert, who is one of our developers has released an app to the app store while in free fall during a skydive.

That is true. We can link to it and there's a YouTube video of it. But that's not usually how it works.

KEN MILLER: It wasn't a client app I don't think. I think it was one of his apps, but still.

JAMON: That was a pretty cool way to do it. But no, you would think that would be the most exciting time. The exciting time is usually during design, for me, because I feel like you start getting a lot of enthusiasm, the energy. A lot of those things start coming out during the design process. And when we get a chance to use our design process—some clients will come to us with something already designed, others will come to us who need design. When they're going through the design process, it's really exciting, you can see a lot of the possibilities. The development side of things is also fun, but a little slower moving.

TODD: I agree with Jamon on the design side. Once we get through the product development and start getting into design, probably past the wireframing and into some more concrete examples, it's pretty fun to see the client get really excited. Especially if it's a situation where they show people who are interested in their product, or their stakeholders and investors, or whomever, and they had a good reaction to it.

I would add the second most fun time with clients is once there is a beta or an alpha available for their beta testers. And again, they send it to them and they use words like "blown away," or something like, that's awesome. I'm not gonna lie and say, that's always what happens, but those two times I think are the most fun to me.

CHRIS: One of the things that Jamon wrote in Slack that was interesting is: what are some common assumptions that clients bring to the process that have to be corrected?

TODD: I don't know if there's anything that's common or consistent across clients. There are some things that come up. I would say, depending on the experience level of the client with software product development, we may have a little to a lot of teaching to do. And that's one of the things we like to do is teach.

I find it particularly fun when our start-up clients are newer, they're not on their series B or something. Because there is a lot of moments that you can help them and give them kind of golden information. Both from our personal experience running start-ups, but also we work with a lot of start-ups. So we've been through this before.

There are some misconceptions about software. Not necessarily from our clients, but from people who weren't a good fit for us. For example, it's very common in the world at large, to believe software is orders of magnitude cheaper than it really is. People also get very used to the quality that they see in apps like Facebook or Gmail, or these kind of things. And they think they can spend less than a car to get those things.

When you're in our industry of course, that doesn't seem super logical, but from their perspective it makes sense. An app costs nothing, or $1.99.

JAMON: Right.

TODD: Or $4.99, so of course something like that seems cheap. What they don't know, of course, is Facebook has tens of thousands of employees.

JAMON: Y...

In this episode, the founders of Infinite Red—Jamon Holmgren, Ken Miller, and Todd Werth—are talking about Chain React, Infinite Red’s React Native tech conference this July 11-13th in Portland, OR. Hear the story of how the conference came about, how Infinite Red's remote team worked together to create an in-person event, the value of hiring people with diverse interests and backgrounds, and all of the things that go into making the best conference possible.

Show Links

• Chain React 2018
• Derek's Food Report

Episode Transcript

CHRIS MARTIN: In 2017, Infinite Red started Chain React, a conference devoted to React Native. So the question that I have for the three of you to start is: why start a conference and what was the need that you saw?

JAMON HOLMGREN: This is Jamon and I was on Twitter and I was looking for a React Native conference because we had been doing React Native for about a year at that point. And I was thinking, well, it'd be really nice to see if some of our team could attend a conference and potentially maybe share some of the things that we had learned along the way. So I actually put out a tweet saying, "is there a React Native conference around? I'm not seeing one." And got no responses, which partially had to do with my very small Twitter audience at the time and partially just because there wasn't one. Now, it turns out there was one over in Europe, React Native EU, put on by our friends over at Callstack.

TODD WERTH: But that was after.

JAMON: I believe it was after that.

KEN: We didn't learn about that until after.

TODD: Not at that time.

JAMON: Right. I was just kinda chewing on that. Wow, I didn't get any response to that. I would normally get two or three options if I were to put out something like that. And I woke up one morning, I'm like, you know what, maybe we should do a conference? And what is funny is independently two or three people contacted me after that, that same week saying, "Do you think we should do a React Native conference?" Just independently and it just seemed like that all kind of came together all at once.

TODD: And this is Todd, Todd Werth, by the way. Some background here. We've never done a conference at all. We've of course all attended conferences. We're familiar with that. Although Shawni Danner, who ran the conference had never attended a conference, which was funny, but anyways, so Jamon came up with the idea, talked to some other people in our company, they liked the idea and then pretty quickly we decided and then we started building the conference.

KEN MILLER: At what point in there did Gant ... Because Gant, who is our social butterfly...

TODD: Gant Laborde.

KEN: ...so he asked around various people to see whether they would speak. And I don't remember if that was before we decided or after. I feel like that was before. We were kind of mulling the idea around and he was like, "hey, we're thinking about doing this conference. Would you want to speak?" And when a bunch of people were like, yeah, hell yeah. We were like, okay, sounds like the stars are aligning, and it was very much a feeling of the stars aligning to be honest.

JAMON: It really was.

KEN: This signal is kind of like once we started putting the idea out, it just gathered momentum from a bunch of different places and we're like, okay, and then once you commit, the momentum increases.

TODD: And as far as I know, it was the first React Native conference in the world.

JAMON: As far as the first one that was held, I think Callstack announced their conference before we announced ours. But yeah it was right in that same time.

TODD: Correct, they announced, but theirs came after ours actually.

JAMON: Yeah, theirs was in September, ours was in July of 2017.

CHRIS: So when you're putting on a new venture, like a conference that you have no experience in and you start seeing the stars align and you start seeing this momentum form: how do you really go from zero to one?

KEN: I don't want to say it wasn't hard because a lot of work went into it, but it wasn't super difficult. At the end of the day, the hard part about making a conference is making a good conference. You get a venue, you get speakers, you get food, you get swag. I mean, I don't mean to oversimplify it, but if you've planned a wedding, you can plan a conference, right? I...