Frontside alum and original podcast host, Brandon Hays, makes a special guest appearance to talk with Charles about the evolution of The Frontside as a company: where it's been, where it's going, and more hopes, dreams, and goals for the future!

CHARLES: Hello everybody. Welcome to The Frontside Podcast Episode 100. Here we are. Episode 100. My name is Charles Lowell. I’m a developer here at The Frontside and I think it’s safe to say, your official podcast host. With me to celebrate the 100th episode, he was also here a few episodes ago but also was here on our first episode I believe, is the [inaudible] Hays. Hello Brandon.

BRANDON: Hi.

CHARLES: Welcome back to the podcast.

BRANDON: Actually, are you going to light your trainee badge on fire now in a bucket, in a ceremonial pyre?

CHARLES: I live in New Mexico, so I think I’m going to just after this, grab my shotgun and give myself a 21 gun salute. Just in my front yard.

BRANDON: There goes old man Lowell again, with the shotgun.

CHARLES: I’m just going to [gun shot sounds] in my own honor.

BRANDON: I was at the Alamo this weekend, actually. And I don’t know if it was just because it was fiesta in San Antonio but they had a demonstration, like a musket firing demonstration where those things are basically little cannons. They’re just small cannons. It’s very interesting. They’re very loud.

CHARLES: Yeah. They’re small, handheld cannons, yeah. So wait, were you – what is fiesta? Now, as someone who grew up in Central [inaudible], I feel like I ought to know this.

BRANDON: I don’t know. We found out by accident because we were planning a weekend to go hang out and get drunk on the riverwalk and we took our families down with some friends and then they’re like, “Oh, it’s fiesta,” which is like a 10-day celebration of the history and establishment of San Antonio – which I did not know is a 300-year-old institution. So, it’s like one of the oldest things in this entire western United States. So, it’s pretty neat. It’s different. It’s weird. It’s like 90 minutes from Austin. There’s nothing in Austin that’s older than six months. Every six months we must demolish something and then build a condo skyscraper in its place.

So, it’s kind of neat to be in a city where it has – walking around the Alamo, I’m realizing, “Wow. Setting aside any of the historical significance of Texas independence or whatever, this is just like a really interesting very old building. This is hundreds of years old in an area where there’s nothing that’s hundreds of years old.” So yeah, it was pretty cool. It was a good weekend and we got to see muskets being fired. And we saw a doctor gross my kids out by talking about the medicine of the day, in full costume and showing all of the procedures and threatening my kids with amputation. And it was a good time. We all had a good time. My nine-year-old thought it was the coolest damn thing he’d ever seen.

CHARLES: Really? Did the have bloody saws and everything?

BRANDON: Oh, yeah.

CHARLES: Was it like a reenactment of 300-year-old surgery?

BRANDON: It wasn’t a full reenactment. But it was a graphic description using the tools of the time.

CHARLES: Wow.

BRANDON: Highly recommend, check out the Alamo. Super fun.

CHARLES: That does sound really cool.

BRANDON: I did not expect to have a good time and it was a good time.

CHARLES: Yeah. Yeah, I know the whole reenactment with the musket firing is fun. And it is, it’s actually an incredible building. Although there’s been a big kerfuffle about something about how they’re going to preserve the lawn. But I haven’t really followed that too much.

BRANDON: Yeah. Yeah, I don’t care about the lawn. I care about – no offense, lawn, if lawn is listening. This is not weird, how Stanley broke our brains with the word ‘lawn’.

CHARLES: That’s true.

BRANDON: Yeah. He broke us real good.

CHARLES: Yeah. I can’t see a lawn without a beard.

BRANDON: So yeah. So, life has been pretty good, man. Let’s see. I left Frontside September, October.

CHARLES: 2016.

BRANDON: 2016.

CHARLES: So, it’s been months.

BRANDON: 18. Yeah, thereabouts, right? So, I assume that nothing happened since then and if I came back to The Frontside now, everything would be exactly as I left it. My posters are still up in my room. My Bon Jovi poster. You left my bed just as I made it, like kind of unmade. Everything is just preserved as a shrine to me.

CHARLES: Pretty much. I mean, we did give away the mics to Goodwill.

BRANDON: No.

CHARLES: We actually did not give away those mics.

BRANDON: I never even got to use them.

CHARLES: I know. Well, you know part of the problem is we don’t even get to use them that much either. It looks really cool and it plays really well, like our podcast studio. But you know, I’m now spending 75% of my time in Corrales, New Mexico. And at any given time, people are either working from home, or working remotely. So, a lot of times the podcast room tragically does not get used. But it looks so cool. People come in there and they’re like, “Wow, you guys must be really smart and technical people.”

BRANDON: I realize this is probably a rote stereotype at this point, but I am assuming the only reason that you moved is that you are dabbling in the production of meth.

CHARLES: Pretty much.

BRANDON: It’s like, I want to learn a new trade. Programming, it’s just – programming, how interesting does it stay honestly for 25 years?

CHARLES: Right. Yeah, and you know, we’ve got some good techniques. Continuous integration, deployment, things like that. Test-first. These are things that can be applied to different verticals. And I was looking…

BRANDON: [Laughs] We ship meth to production on the first day.

CHARLES: Right. [Laughter] Exactly. So, I figured it was a market ripe for disruption.

BRANDON: [Laughs] It’s probably true. So yeah, I wanted to ask you about that. You all kind of scattered to the four winds in some ways. You have Elrich in Boston and you’re in New Mexico most of the time.

CHARLES: Joe is in [inaudible].

BRANDON: Oh yeah, Joe moved to New York.

CHARLES: Yup. And honestly, the traffic is so bad in Austin that I’d say 50% of the time, people stay home rather than drive into our centrally-located office. So, that’s actually something that we’re struggling with right now because the bulk of the team is still in Austin. But the office space is underutilized. Our team size now, we have eight engineers. And five of them are in Austin. Our other staff is also in Austin. So, what do we do with the office? It’s a big question.

BRANDON: And that’s quite a cultural change, too. Because when I was there, we would tell people, “We want to be able to do remote someday. But we just don’t know how to get into that culture to change the way that we do our meetings and change the way that we do standups and coordination and communication.” I didn’t feel like we had the tooling at the time. So, something – I knew that at some point there would be probably a forcing function to basically catalyze something to allow that to work. And I’m curious to know what that process was like there.

CHARLES: I wish I could say that there was a process other than experiencing the force of the forcing function and then being forced into it and then just kind of dealing with it. I have not taken a poll of the other remote employees of which now I am one, at least for the time being. So, I don’t want to speak for them. But it was less painful than you might imagine. And the reason is because – and it’s one of those things you actually gave me this analogy back, probably three or four years ago and I love it – is sometimes you’re hanging off of a precipice and you don’t realize that you’re toes are two inches off the ground. And then all you can perceive is the precipice and you feel the weight of your own body concentrated on your fingers gripped to the ledge. And you don’t focus on the fact that you’re actually, the fall is only two inches long. And that’s kind of what we experience with the remote culture.

Now, I don’t want to say we were Pollyanna about it and didn’t realize that this was the step that we were taking and making sure to check in with the remote employees. But one of the things is our communication styles were already very asynchronous both for our client work, for our internal work, using mostly Slack and GitHub pull requests and issues – certainly for the development portion, very little changed. What we didn’t realize is that because of our involvement in open source, we were already acclimated to a distributed work style. We just didn’t really realize it. We didn’t have to change much. I think where we have a lot more work to do is kind of integrating people socially and making sure that conversations don’t happen that aren’t available for other people to consume asynchronously. So, if you’re having some architecture problem and you’re sitting next to somebody, you’ll take that avenue rather than let it play out in chat or over email. And there is definitely a certain portion of that, but I think we still do a lot of pair programming. That’s still our major mode. I’d say 75% of our code gets written as people collaborating. And so, while those in-office discussions do happen, the ramifications circulate rather quickly. And most of those are in the context of people pairing inside the office. Does that make sense?

BRANDON: Mmhmm.

CHARLES: So, I don’t think the office and the physical space were as much of a bottleneck as we thought they might be. And so, because of the – a lot of people did work from home already because of the traffic. And we were involved in open source. And our communication with our clients is usually – we don’t currently have any clients in Austin. So, that’s all to say that the transition was actually quite natural. And I think there’s some strong analogies between collaborating in open source and having a remote culture in your office. I think what we need to get better about is making sure that we get the team together at least twice a year, everybody together. Making sure that people are able to understand their priorities and get to circulate around and get introduced to a bunch of different people. And yeah, I don’t know. There’s definitely a lot of work to be done on the non-development front.

BRANDON: It’s interesting. The agile approach to things is to try something. I’m starting to think the agile and the scientific method are related where it’s like, “Here’s a hypothesis. Here’s the experiment. Here’s what we think we want to learn,” and then you learn it and you take the next step based on that information. And that failure is an option. I think that’s the point of agile, is to make failure safe because it’s small and you’re guaranteed to learn from it. Like, the point is to learn. And so, I really, I’m starting to think that those are just basically the same thing. That agile is like the application of the scientific method to product development. And it sounds like you’re being agile or experimental about your work. And the trick is, like any scientific discovery, the trick is in coming back around to it and analyzing it and deciding whether this was successful or a failure based on feedback and finding what the measurement was that you were trying to improve. So, the lesson there was, “Oh, people become disconnected from each other. We need to gather everybody for an all-hands periodically.” We didn’t use to have to do that because all-hands was every week, at least.

CHARLES: Right. Yeah, everybody was constantly – there was a constant chatter and you could just kind of, the context was just all sitting at that one table, in that one room on 38th Street. And all you needed to do was dip your ear into that pool of context and you’re set. Whereas that’s just not an option right now. So yeah. I think the danger with agile is not being concentrated in your experimentation. I think what gave us our fear about saying we’re going to do remote work – because I remember we always talked about it. We danced around the issue – was are we going to lose who we are? We have a set of way that we do things. And there is power in kind of sticking to the framework of the way that you do things. Because you understand it and you know it.

So, when you’re pushing and you’re experimenting, being able to say, “We’re going to – push and we’re going to focus on this one area and we’re going to iterate on it and we’re going to keep everything else static,” it’s going to be the wall that we can walk along. But we are going to push in this area. And so, I think the dangers of you doing that in all the areas of your business or all the areas of your project, you’re iterating and refining, nothing ever gets done. And so, it’s kind of like once you get to some ground that’s solid, when you do start iterating it, you start introducing instability. So, when you go remote you have to start thinking about remote work, whereas we didn’t have to think about that before. We were essentially, the feature of saying that we were a one-office company and an on-site company is we didn’t have to think about that problem.

BRANDON: One thing that you were just taking about is this idea of concentrating so that your experiments are happening one or two or maybe three at a time instead of trying to run five experiments at a time. And yeah, there’s another danger I think in agile of seeking local optimization where you’re basically like – it’s like taking a bacteria and running it through many, many, many iterations that’s targeting one thing and it mutates into this weird thing that only does this one thing. Or a dog breed that the whole – did you see that, I don’t know where this came from but there was some scientific findings that there was a dog that was bred in ancient prehistoric times that was bred to turn a spit to roast meat over. So, they bread a dog that the whole point of this dog was to turn a spit so that people could roast meat and go to sleep and let their dog serve it, cook for them I guess?

CHARLES: Wow.

BRANDON: That’s pretty impressive.

CHARLES: I would say like their dystopia is in the past. Or certainly canine dystopias. I guess we live in a canine dystopia.

BRANDON: Not in my house.

CHARLES: Not at your house.

BRANDON: This place is known as a canine paradise. So yeah, I think that’s a really interesting point though, that limiting the number of concurrent experiments so that you can actually respond to them in a meaningful way instead of just being like, “Wow, we learned a bunch of stuff we’re doing wrong. Anyway, back to the grind.”

CHARLES: [Laughs] Yeah.

BRANDON: Back to sucking at everything.

CHARLES: Right, right.

BRANDON: That kind of feeds into a lesson that I have learned very, very, very recently in the interview process for looking for my first real job in over a decade. And that process is very humbling. And one of the humbling experiences was being rejected for a job from a very notable larger former startup here in Austin. And their interview process is really buttoned up. I got really deep into the interview process and at the end of it they’re like, “Oh, you’re not technical enough.” And it was really, it was like, I don’t know. It was hard for me to process at the time but it’s super easy now to look back and go, “Oh, I was definitely not a fit for that type of job if being able to write JavaScript on a whiteboard without the aid of Google to solve problems and refactor code is like a fundamental part of what is valued in a manager there.” That’s just not going to be me.

But one thing I – and it wasn’t a colossal waste of time. There was a ton of time and energy I invested into that specific process, but I actually derived a ton of value out of it. Because every person I met there was focused on the same thing: their culture of making experimentation inexpensive so that everything there is framed in terms of an experiment. What’s the experiment here? What’s the hypothesis? What’s the expected outcome? How soon can we get to a place where we can validate that outcome? So, it’s kind of like everything is really lean. And yes, it does – like I asked, “What’s the dark side of that?” and it can lead to optimizing for a local maximum. So, you have to pause every once in a while and reflect at a larger scale. But it changed my attitude about a lot of stuff. I tend to walk around fearing failure. That’s more my speed. I’m afraid of failing because failure can be catastrophic. But that’s because I take big swings at stuff. When I go give a conference talk, it better be the best conference talk of my life. When somebody’s like, “Oh, that was the best conference talk I have ever seen,” I’m like, “Ah. I’m so glad you said that because if you’d said literally anything else I would have collapsed internally.” You know? The stakes are so high for everything. And making it safe for yourself to fail by treating things like an experiment and working with my teammates.

And so, two or three scenarios over the phone in a week when I was managing the team at my last company, somebody would bring something to me and I’m like, I instantly went to all the reasons this probably won’t work. “Here’s the problem with this.” And I thought, and I immediately turn around and went, “Wait a minute. Bring me a hypothesis and the experiment and how we can experiment with this thing.” And he’s like, “Well, we could try this next week and we’ll know whether or not this is a good idea.” And we tried it the next week. It was like organizing an architecture team because we were waiting to hire an architect. And the results were mixed for reasons I won’t get too deep into. But the fact was, it gave us the freedom to try things. And I’m trying to carry that spirit around with me now. It’s been really eye-opening. So, completely like, just a 4% alteration in the way that I think about problems, but it has the ability to dramatically alter the trajectory of how I solve things in the future.

CHARLES: So, do you include now inside the planning process experiments? Like, a certain number.

BRANDON: Absolutely.

CHARLES: So, the typical “enterprise” development is we have our features, we’re going to do them in this order because they’re this priority. And then agile comes along and it’s like, “You need to take these things and you need to break them up into small chunks so that they can be accomplished in small time slices,” so that you don’t basically bark up wrong trees. Or explore [inaudible].

BRANDON: Yeah, but that’s almost like a stupider version of waterfall.

CHARLES: But exactly. That’s exactly my point. Whereas the problem is, there’s no avenue for experimentation in there. Rather than saying the entire team is marching in this one direction that meanders around and focuses in on the local maximum, which hopefully is relative to the market landscape is the absolute maximum, saying, “We’re actually going to be marching in one major direction but we’re going to be sending out scouts at all points.” If you were actually – I’ve actually been reading a lot of ancient military history. And It’s just insane that an army, or even a detachment, would go all in one clump. They’re constantly sending out people. Information is really, really, really important.

BRANDON: That’s an extremely, extremely good point. I’ve actually – it’s so funny, because I’ve used a very similar description where we are trying to chart a course to this ocean of opportunity somewhere. And we can’t just send the whole team in a direction hoping that the ocean is in that direction. We have to have our Lewis and Clark. Somebody has to be the cartographer. Somebody has to be the explorer. And that means that there has to be a little bit more freedom for those explorers. I don’t yet know how to translate that into software terms. I just know that that’s a collaboration usually at most companies between product and development. That product is doing some of the exploring of the space and then development is doing some of the exploring of the technical capabilities and possibilities there.

CHARLES: So, you see it. What’s interesting is you see it in product planning, kind of in the large, with the waterfall. You see it in huge organizations. They have a research and development department. And I wonder if agile kind of saw the Balkanization of your feature set into very small component parts. Can you take the exact same principle and Balkanize your research and development and integrate it into micro-iterations? We have this R&D but we’re going to integrate it into our day-to-day and week-to-week process.

BRANDON: I think that is a really noble goal and I think I see some people making progress toward that. The company I interviewed with does it almost to a pathological degree where there is a point of diminishing returns where you’re sort of bound to this process of experimentation. And at a certain point you can only achieve incremental results.

CHARLES: Some of these problems, you just need to be able to think about them for a long, long time. I actually didn’t read, I actually didn’t see the talk. But everything from the title, Rich Hickey’s ‘Hammock Driven Development’, just that title resonated with me so much. I was like, “Yes,” because sometimes you just need to be in the hammock for six hours at a time. Or in the shower. Or hiking. Or doing whatever it is that you need to do to put yourself in a zen state where you’re just, your brain is slowly turning its wheels. And it can follow every lead to its conclusion without any interruption. And sometimes that process can take hours. Sometimes it needs to take weeks.

BRANDON: Right. I want to kind of pivot on that. Because that’s actually one of the biggest things that I’ve learned in the intervening time since leaving Frontside, which is creating space instead of trying to maximize – one thing that I did when I was at Frontside and then did again at my next place and I’m realizing is really has long-term negative implications is cram as much into a work day, as much output out as possible. I’m very output-oriented. I want to jam as much into my day as possible. I want to jam as much software out the door as possible. And people describe working at Frontside while I was there as one of the most intense work experiences they'd ever had. Literally, I can project that, literally just from my own intensity of trying to cram all that stuff.

And providing that space for developers to ruminate on hard problems, on some of the harder problems they encounter, providing space for managers, I’ve learned that a big chunk of what it is to be a manager is to be available. And so, I actually want to write a sign – I was on the fence about doing this but I think I’m actually doing to do this – I have an office and I’m going to write a sign and put it up on the door that says, “If I look busy, interrupt me and remind me I’m not doing this right.” So, creating the space to ruminate or to be available for discussion, people that protect their breathing room sometimes are made fun of, especially in American corporate culture. I walked in and they were just reading a newspaper. What the heck are you doing at work if you’re just going to read a newspaper? Like no, this is actually really important time.

CHARLES: I think it’s, yeah, it’s something that I think about a lot. And I know I’ve shared this analogy with you before. I don’t know if I’ve done it on the podcast. But I saw and I can’t take credit for it. I actually saw it at DevOpsDays I think in 2013. There was a woman giving a talk and she was just talking about managing developers. But one of the things that she was saying was that if you looked at a microservices architecture or you looked at just even your operating system, and if your CPU was constantly pegged, you were squeezing out 100% of every time slice, instructions were just flowing through that, you’re going to have a very unhealthy, very brittle, very prone to failure software system. If our microservices were not available to actually service requests, and service excess requests, and service spikes of requests, then something is fundamentally wrong.

BRANDON: I want to add to that a little bit, because the thing that I noticed in managing a team where I received a ton of pressure to peg everybody out at 100% – and it jived with my philosophy at the time of, “Hey, I’m 100% guy. Everybody I work with is 100% type people. And then, let’s peg everybody at 100%. This is a startup. Let’s get everything going,” and I realized very, very quickly that if you don’t preserve a little buffer, 20% buffer in that level of intensity, there is no ability to share resources. Everything is now a silo. So, if you’re going to peg all your CPUs out, part of that thrashing is that there’s no time for people to share things with each other. And people become very protective over their little silo all of a sudden. And it causes us – it’s actually like the first stage of a catastrophic cultural collapse if everybody’s pegged out at 100%. And literally, just dialing down the intensity is often the only thing that’s necessary to get people to feel comfortable sharing some of their time with each other. You do a really good job of that with the lunch and learns. You mentioned that y’all are doing better thoughtful lunch and learns and stuff like that. It’s one of those forcing ways that you can force that and say, “Hold on. Stop the development and do some stuff where you’re actually sharing things with your teammates.”

CHARLES: Yeah. And we do that. My biggest concern is that that actually increases the intensity. So, one of the things we’ve done is we used to actually be very formal about our lunch and learns. It’s like, “We’ve got to generate content and put it out on the web so that people can see us.” We backed away from saying – we’re not going to do them as often and make sure that people can actually do them. Yeah, making sure that people don’t feel overwhelmed by, “I’ve got a lunch and learn coming up.” The point is to share something that you’re passionate about and maybe introduce some really cool ideas to ferment in people’s head. Rather, that’s kind of the goal. There are certain things that we do very much feel interested in generating content. But I think, we’ve kind of been dancing around the ideas of distributed computing and IoT and what are some of the others?

BRANDON: If you say blockchain, I’m going to just virtually punch you in the face.

CHARLES: [Laughs] I actually didn’t. Did I say blockchain?

BRANDON: No. I just was waiting for you to say it.

CHARLES: Okay, no. I haven’t. Well, because that’s – but it is distributed computing in Web 3.0, right? These problems – and we’re actually going to be podcasting about this next, so in two weeks you can tune in to listen to us talk about blockchain but in the context of distributed computing – and one of the things that we’re seeing is now we’re starting to pay the price of outsourcing all of our lives to these central services like Facebook and Google and Amazon. And I think now they’re starting to build a credible and more mainstream movement to wrestle back that control and say, “What would it mean to have software as a service that wasn’t actually dependent on some central thing?” What would it look like to have Slack where it’s Slack that looked like email? Where everybody had their own email server, maybe not a bad example. But you’ve got an email at Gmail or Microsoft or Yahoo or your company-run that’s big enough its running its own Outlook client or something like that. Email is actually a really great example.

Now probably people are going to crucify me for saying this, but I think it’s actually a good example of a distributed system that’s worked well. I own all of my email. All the messages that you send to me, I own, and all the messages I send to you, I also own. But you also own the messages that I send to you. Information is duplicated. And it’s fine. If I send you an image, yes it’s on your hard drive or it’s on your Google Drive. You send a message to me, it’s got an attachment, I also have that attachment. But the point is that we can each own our email and we each own our email service. And we can change it up. That’s not possible with Slack. That’s not possible with Facebook. That’s not possible with all these other sharing platforms. All of them are controlled by this one thing. And so, I think that that’s something that we've been exposed to through the lunch and learns and I’m actually certainly very excited about it. It’s not something that we’re going to be investing in immediately. We’re kind of dancing around that idea. But that’s something that’s come out of that. So yeah, we’ve kind of refocused it on, what is something that you feel good about?

But back to the original point, I think that this is something that applies on all fronts. If you have a business where you can’t actually take opportunities because you don’t actually have people – so there’s maxing out at the individual level, filling up people’s workspace with client work or filling it up with what have you or having them work nights and weekends. There’s individual maxing out but then there’s like maxing out of your business. So, if you have – we’re a consultancy – if you have 100% utilization or you’re shooting for 100% utilization, that everybody is placed on a project, that is a brittle and unsustainable system.

BRANDON: I wish you would have told me that 18 months before I left there. There were like two years where we were at 100% for two solid years.

CHARLES: Yeah, yeah. We’re still at 100%.

BRANDON: Yeah. I wonder what would have happened if we’d had a little, if we had figured out how to build in space.

CHARLES: Part of the problem – so, here’s the thing though. Space, nice space costs nice money.

BRANDON: Yeah.

CHARLES: And so, that’s the thing, is you have to charge more. And you have to say, “We are going to be more expensive than other people.” You have to be dedicated to be at the forefront of a cultural battle, essentially. In the same way that people were with testing, where it was very [controversial].

BRANDON: Yeah. You were with CI. CI is a given now, right? CI is…

CHARLES: Yeah, like [inaudible].

BRANDON: This idea was semi-revolutionary when you and I were talking about this in 2012, 2013, that we ship to production on the first day. We don’t even start building software until the CI system is set up. The first thing we do is set up Jenkins and tests and get everything, the pipeline working. And now, that’s just what people do. By and large, that’s how software is expected to be built. And the tooling has really come up around that. But that was an expensive way to sell software five years ago, that, “Hey, this is going to cost more than bringing in Cowboy Bob and having them come jam in your console for 40 days and ship a bunch of stuff that then will most likely collapse and you won’t know about it and Cowboy Bob has ridden off into Juarez, Mexico.”

CHARLES: Right, with his saddlebag stuffed with your cash.

BRANDON: Yup.

CHARLES: Yeah, no. So, you have to – the problem is, you know when you pick these battles, you need to be prepared to fight the war of attrition of they’re not going to be able to perceive the value for six months, a year, right? You’re going to have to ask your clients to bet on this strategy. And it’s a bet. And you’re going to have to say, “It’s going to pay off in six months. It’s going to pay off in a year.” And you’re really going to start raking in like five years. That’s when…

BRANDON: Yeah. Try making that pitch to a startup founder that is borderline, that is on the verge of an anxiety attack, and you can kind of just figure out what my last year was like. And the…

CHARLES: So, that’s one of the reasons we don’t really work with startups anymore. They have a five-year plan, but not really.

BRANDON: Yeah.

CHARLES: They’re fighting for their survival. And they’re fighting for the opportunity to have a legitimate five-year plan. And so, in that sense, it’s maybe not a good fit for the way that we develop software, because you either need an extraordinarily prescient founder who has been through this before, knows the true costs of software development, and is pretty well-funded so that they can actually – because we’re more expensive upfront, like a lot more expensive upfront and so sometimes they flat out don’t even have the cash. And that’s something that you can make a quick, “It’s not a good fit,” but then there also needs to be this understanding and an acknowledgment that what you’re really shooting for is your five-year dividend.

BRANDON: Yeah. It is really interesting, the turn that occurs when a company finds product/market fit. By then it’s too late to fix the problems. So, it’s really tricky to find the balance of: how much energy do you put into the success case for a company before they have product/market fit? How much time and energy do you invest in betting that this is going to be successful versus betting that if it is successful, hopefully we’ll have the time, money, and resources to redo a bunch of the things that we are going to have to apologize for later? And I think that’s what makes…

CHARLES: Right. Like, where do those two lines cross on that graph?

BRANDON: Yeah. Because you and I have both seen startups completely sunk by somebody who was overly focused on building a scaleable architecture in a company pre-product/market fit. That is a common story where an engineer that doesn’t understand the business value of what they're doing and only focused on “quality” will absolutely torpedo, they’ll chew up your first million and a half of funding and leave the place in just a smoldering pile of ashes at the end. So, it is tricky. It’s totally a difficult thing.

But I think coming back to your point of being sort of a vanguard of cultural, the tip of the spear on somebody’s cultural changes – DevOps would be one. People that were really investing in DevOps culture in 2010, 2012 saying, “Hey, this, automation, is the future of how software gets shipped, maintained, observed, supported.” And so, now it sounds like, so what is your big bet for the future?

CHARLES: Boy. That’s a great question. There are two bets. One you’re going to like, one you’re going to vomit.

BRANDON: [Laughs]

CHARLES: But that’s okay.

BRANDON: Yeah. I don’t work for you.

CHARLES: You need to serve, what is it? You need to serve the spiny urchin with the yellow tail.

BRANDON: Is that a Sonic the Hedgehog reference?

CHARLES: It’s just a sushi reference.

BRANDON: Oh, okay.

CHARLES: Some people don’t like urchin. Or maybe they don’t like eggs. What it like, the roe that come with sushi. But they’re on the same plate.

So, I would say the first one that I’ve been thinking about a lot is optimizing for capacity and being able to handle spikes and not being at 100% both for people and for utilization. I think that’s something that is – I don’t see how you could have a healthy software development process if people are completely spiked on delivering, heads down delivering features for product. That is something that I’m betting on. Essentially, you could call it the 25% time but it’s really about having excess capacity to exploit opportunities as they arise. And then being protective of that excess capacity. Because you can exploit an opportunity. Your CPU has a spike load up to 100%. But then make sure you [inaudible] down to 50% at some point, or 75%. And so, I would very much like to see Frontside have a bench where people can rotate out and they’re working on different stuff that are not even client-related. They can recharge their creative tanks. They’re not going to be idle.

BRANDON: Yeah, I’ve really come around on – and I really hated this at the time – but I’ve actually come around to the thoughtbot style of working on a product where – because owning and managing a product and developing it as a side quest, the goal is not necessarily for that product to catch fire and become the world’s next big thing and to replace your consulting revenue. The goal is to give people a sense of – think about all the stuff that you’ve learned in your side projects that you went back and brought to your work. And some of my biggest gains as a developer have come from having a side gig of some kind, some side project that that’s how I learned Ember. That changed my life. And I would never have gotten to try it if I was waiting for somebody at work to tell me it was okay to do it. So, it’s about taking that permission back for yourself and giving yourself permission to try stuff.

So, it could be something like that, or it could be the content stuff that y’all do. Or it could be conference talks. It could be whatever. But the goal isn’t necessarily to produce things that have a direct return. It is to create the space to allow people to flex some muscles of creativity that you may not get in your day-to-day work. And that’s very difficult to offer to people in any company. Now having explored startups and larger companies, but I would say especially in a consultancy where the exchange rate is dollars for days. It’s sort of like when I was freelancing. I could feel every vacation I took draining both real money and opportunity money out of my bank account. That’s such a hard, difficult thing to do. And so, you actually have to create the budget ahead of time and say, “This budget is allocated to these things and it’s already spent.” Anyway, that’s really tough to do.

CHARLES: It is hard.

BRANDON: If you can exercise the discipline necessary to do that and create the environment for that, I would say you’re ahead of 90% of companies in the industry.

CHARLES: Yeah. Yeah, so that’s something I definitely want to bet on, because I think that’s where the best things come from.

BRANDON: Okay. So, what’s the thing I’m going to hate?

CHARLES: Functional programming.

BRANDON: Oh, Charles. Okay, I have to stop you. Do you know what I’m doing? Did I tell you this yet? That I am participating. When I told them this, I was like, “Charles is going to have a field day with this,” but I am participating in a Haskell study group.

CHARLES: No way.

BRANDON: And I’m like four exercises into this thing. I have to do four more for next week. And I’m like, “This is bizarrely easy, actually,” after as much JavaScript as you and I did in sort of a functional style and then learning Elixir. And I was like, “Wait a minute. The case statement is, Elixir just stole Haskell’s case statements.” So like, so far I’m not finding functional programming to be onerous. Or anyway, but we’ll see when we get to the static typing. But so far, I’m not getting any of that in the earlier lessons of the book.

CHARLES: Yeah, the static typing. But the thing is, you can do – it’s not 100% necessary. It isn’t in Haskell, for sure. But I’m surprised. What inspired you?

BRANDON: We have an architect at the office that was like, “Hey, I want to do sort of a functional programming book club.” So, we have a Slack group for FP study group.

CHARLES: Are you doing ‘Haskell: From First Principles’?

BRANDON: No. That one was a little actually intimidating.

CHARLES: Really?

BRANDON: Yeah. It gets into the lingo a little early. And we’re doing one called ‘Get Programming with Haskell’ that is a little more – ‘Haskell: From First Principles’ is kind of math-oriented. So, for somebody with a math background but not necessarily a programming background, it’s perfect. But for somebody with a programming background that is just trying to understand functional programming principles using Haskell, ‘Get Programming with Haskell’ is actually a really great option.

CHARLES: Okay. Actually, I have not heard of that one.

BRANDON: The stuff that I’m looking at looks just like Elixir. So, it’s early. But it’s very comfortable so far.

CHARLES: Yeah. So, this is the thing. It’s all a matter of messaging and marketing. Because I really feel – so, it is like there are a lot of behaviors that you see sometimes in currently entrenched functional programming communities that I think are, well I think they’re objectively repulsive. But I think they’re also pragmatically repulsive and that they repulse potential community members. But I think a lot of it too is people talk about these things that are, they use abstruse terminology. And they’re kind of chattering back and it’s very jargon-oriented. And there’s just – people operate with a different set of concrete things. So, when you and I are talking, for example we might talk about a Rails controller and that’s a very concrete thing. You know exactly what I’m talking about. It’s something that you have held in your hand, literally. Remember when we got that Rails codebase that came as a thumb drive?

BRANDON: Yes I do.

CHARLES: But the point is you knew that this had a Rails codebase on it. There were any number of controllers. And when I say controller to you, a controller is an abstraction, but not really. Once you work with an abstraction long enough, it becomes concrete. And so, part of the problem is just a mismatch in language where people are talking in their world about concrete things, things that you can touch and you can feel and you can exchange and they’re very relatable. But from another person’s perspective, they’re talking about something that’s totally abstract and totally opaque and totally what have you. And so, I feel like yeah there’s a huge mismatch there. And that’s been one of the big bets.

The other big bet that I’m making is on this trying to make what is currently abstract to JavaScript and Ruby developers be concrete. And I think that we’re going to see type classes like functor and monoid and semigroup and all these things, they’re abstract to you now, become concrete over the next five years. And so, that’s something that I’m betting on.

BRANDON: Check out this – and I know that you have a good relationship with the people that did the other book, but it really does tend to come from more of a mathematical background. And this one actually does speak to people with JavaScript, Ruby, Python experience. Like, “Hey, here is how you will perceive these things.” And so, it’s much more approachable. I’m still in the first unit of the book. But having sort of tasted it a little bit, it’s like, “Wait a minute. This is actually extremely familiar and not super intimidating.”

CHARLES: Exactly. And that was kind of – so, I read the other book. And I think I was also aided by the fact that I tried to learn Haskell probably for five times in the past. And so, I also had the benefit of jumping against the wall with the velcro suit and bouncing off four times. And fifth time, it stuck. So, I had just temerity on my side and a general feeling. But that’s definitely – the lesson that I actually came away from reading that book was like, “Oh, there’s a mismatch in concrete concepts.” It’s using concrete concepts that are concrete to people with a CS background or mathematics background, or people who are brand new. Honestly, people who are brand new to programming who don’t actually have JavaScript or Elixir or Ruby or any other thing to lean on, I think that the First Principles book is actually pretty decent for them, too. Because they don’t have anything to compare to.

BRANDON: They don’t have anything to unlearn.

CHARLES: Yeah, they don’t have anything to unlearn whereas one of the things I took away was I was like, “Oh, man. I’m using semigroups all the time. This is something that I do constantly.” When I’m coding, I might do it eight times in a day. I just didn’t have a name for it.

BRANDON: Right. They’re like design patterns, just at a micro level.

CHARLES: Yes, micro-design patterns. Yeah, it’s like a RESTful architecture for your code. In REST you only get five verbs. There’s five methods, man. That’s all you got.

BRANDON: Okay, so those are two bets. And I want to cover one more thing because I know we’re super overtime. But the last thing I want to be able to say about talking about what we’ve learned since I left Frontside but I want to put a bow on that. So, the two things that you’re betting heavily on are functional programming as a basis for solid architectures in the future, like the work that you all are doing. And…

CHARLES: I would also like to say, and this is something – let me just add one more thought. What I don’t understand, and this is in no way like, I don’t understand people who do the, “Saying goodbye to framework X.” That’s not me with object-oriented programming.

BRANDON: Often abstractions are like oversimplifications but they’re really useful, sort of like Rich Hickey’s Simple versus Easy. Like, “Hey, there’s a lot of promise with that metaphor. It’s a leaky abstraction but it’s a useful abstraction.” And Gary Bernhardt’s ‘Functional Core, Imperative Shell’ is a leaky abstraction but it’s a useful abstraction. If people haven’t seen or experienced that, it’s pretty good. The subtlety is that these are tools that are suited to certain situations a little better. And those same situations can exist in the same codebase, can exist in the same program.

CHARLES: Yeah. I still, I love Ruby. I adore it. And in some ways, I’ve been researching functional programming and it’s been going on for the last four years. So many times, people are like, “Oh, I just can’t stand this tool anymore.” And I’m like, “Man, I still love Java.” I don’t understand how learning to love something decreases your love for something else.

BRANDON: That happens the first two times that you fall in love, is that you feel like you have the old thing less in order to love the new thing. And then you start realizing, “No, you are allowed to fall in love with new things without falling out of love with the old things.” I would almost use that as an interview question. Is there some way to use that as a way to gauge somebody’s actual real concrete maturity as a developer? Because that is a mark of maturity.

CHARLES: Yeah. I mean, you could say, “What’s some tool that you no longer use that still informs your day-to-day routine?”

BRANDON: Yeah. I guarantee you, people that were doing Smalltalk in the 80s think about it all the time.

CHARLES: [Laughs] Yup. Yeah, exactly. Exactly.

BRANDON: Alright. So, I want to cover one last thing.

CHARLES: It’s part of growing, right? If you’re going to grow as a developer, you can’t be shrinking at the same time as you’re growing. Otherwise, you’re like the same size, just in a different place.

BRANDON: However, you don’t get any Medium think piece points. Nobody does the one clap, two clap, forty, for blog posts that are like, “Why I’m still using some programming language but using one a little more than I used to use and this one a little less.”

CHARLES: [Laughs] Zero claps.

BRANDON: Yeah, zero claps on that think piece. I just want to cover one last thing before we wrap this up, and it is the fact that Frontside, the biggest gift that Frontside gave me was the mission for the next 20 years of my career. I think it could change, but I’m pretty confident about this, at this point. Being approximately 20 years into my career, I feel like I kind of have a feeling for what the next 20 years is about. And the Frontside really drilled that into me and helped me focus it and helped me dial it in.

And it is this idea that there is an incoming generation of programmer that thinks about things differently than the previous generation in a pretty radical way. Because the previous generation all came out of the same schools. They all look the same. They all have a similar shared set of values in general. They created the Sil- – you know, I’m not actually going to be overly critical of the Silicon Valley culture that exists now. It is a result of the type of people that came out at the time that value innovation over almost anything else. People talk about ripe for disruption. The fact is, that has been an engine of economic growth and progress for society in a lot of ways that has a lot of costs that weren’t factored in by a bunch of people who all thought the same way.

And now, with people coming through code schools and people coming from different backgrounds and people coming from different environments, they’re looking at programming and software as either an economic opportunity or something they didn’t see that they could possibly do. Those doors were not open to that group of people before. There is a natural influx of people but many of them are bouncing out because they’re not finding that group of people, they don’t have a shared enough set of values that the people that are new are coming in and finding job opportunities, finding promotions, finding leadership positions.

And so, I know now that my mission over the next 20 years of my career is to create those opportunities for people that have different backgrounds from me and different experiences. The career tracks, the promotions, endorsing and supporting and kind of sponsoring this incoming group of freshmen into our industry that come from different places, different backgrounds, different problems that they care about solving. They want to figure out how to solve the Flint Michigan water crisis instead of delivering socks to people in Silicon Valley, you know? So, I feel like we’re at the beginning of a seed change in the value system potentially of our entire industry. But that’s going to require training up the next generation of technical leadership.

And I felt like the best thing I could do right now is learn to be a better manager, because I really like that job. And it provides the opportunity to find, hire, sponsor, promote and encourage those people to move into their own leadership positions. There are lots of other things that a person, you could be a VC and care about that stuff. You could have lots of different positions and put yourself in a position to do that. You could be a consultancy owner. You know what I mean? There are jobs that you can do that you can accomplish that goal. But it gives me such a sense of direction that when I’m looking for a job, I was looking for a home for that mission rather than just the thing that I felt like doing. Like okay, this job is important to me because I need it to house me and this mission so that I can support my family but have enough emotional overhead to participate in community stuff, but enough ability to lead within an organization, enough influence to actually push that agenda. So that the next generation of people are making better companies.

So anyway, all of that came out of my time at Frontside where you and I sat around talking about: how do we build a place that is like a monastery? These were your words. You remember this? We want a monastery for code where people can just focus on becoming better developers. And underneath that though was the sense that this was a place of opportunity for people that might go somewhere else and stagnate as a developer. This will be a place to accelerate them. And so, that kind of spun me out and accelerated me into my mission. So anyway, I just wanted to point out that that was like, with a bullet, is the most important thing that came out for me in my time at Frontside, was that it clarified for me what I was trying to accomplish with the next couple of decades of my career.

CHARLES: Wow. Well, that’s fantastic. You definitely did a lot of that both here at Frontside and I mean you’re continuing to do that. I definitely want to see more public speaking from you. Maybe some [inaudible] perfect. [Inaudible] at EmberConf was actually fantastic. But I mean, you’re also able to help people find their mission, too. Like the talks you have at Keep Ruby Weird and even really, the first talk you gave at LoneStarRuby about moving Ember. It’s always, how do I adapt what I’m feeling to my overall mission and then relate that back to technology? Man, I just can’t wait. I can’t wait. When are you going to hit the road again?

BRANDON: I think this is the year. I’m going to start thinking about this stuff. I’m looking at the stuff that I wanted to talk about on this podcast and I was like, “Oh no, wait. That’s like a dozen podcasts.” Like, no. Absolutely not. Not possible. I will say, I miss so much, this time that I spend with you. I don’t want to let it go. I really miss working with you. I really miss having these conversations whenever I want. This has been a very, very special privilege for me to be able to do this with you today. And congratulations on Frontside continuing to thrive and grow and become more of its own entity and more of its own special flavor. And it makes me really happy to see the people coming out of there, that it’s still doing its mission of making great software by making great developers. It makes me real happy.

CHARLES: Yeah, yeah. Hopefully we can keep on keeping on. I do miss working with you. I miss the conversations that we would have in the kitchen which are basically an extension of this podcast. But I also, man, I really, really, really, really like working with the group of people that are here today. I’ve just seen them producing just some absolutely amazing things. And honestly, there’s a selfish aspect to it, too. I get stimulated. My own thinking and learning is stimulated by the people that I work with. And like I said, the whole side note we had about distributed systems and IoT and just a constant ferment of things. So, I still really, really, really enjoy it.

BRANDON: That makes me happy.

CHARLES: And I’m really glad that we got to kick it today.

BRANDON: Yeah, me too.

CHARLES: I thought you were going to say that your 20-year mission was to have your perfect Emacs initialization setup.

BRANDON: Oh my gosh. Some of these days, I’m going to figure out RuboCop.

CHARLES: Actually, do you want to pair on that?

BRANDON: Yeah, let’s do that.

CHARLES: Alright, everybody. I’m going to sign off. If anyone wants to continue the conversation, obviously you can get in touch with Brandon. He is misspelled @tehviking on Twitter. T-E-H-V-I-K-I-N-G. Always come at him.

BRANDON: Don’t @ me.

CHARLES: [Laughs]

BRANDON: I work for a really cool company and if you ask me about it on Twitter, I’ll tell you all about it.

CHARLES: Awesome. And we of course are Frontside. You can get us on Twitter at @TheFrontside or just drop us a line to [email protected]. And we would love to talk to you more about this podcast and all the wonderful things that we do here, which includes building custom software that you can stake your future on, that’s going to be good for the five-year outlook. So with that, goodbye Brandon. Goodbye everybody. And we will see you…

BRANDON: Bye Charles. I love you.

CHARLES: Me too.