The honeybadgers have been busy this week! Ben, Josh and Starr each have work that shipped this week that they want to brag on. This episode strides over vast expanses, covering issues like compliance, open-source marketing and content marketing. It all builds up to a big reveal at the end, where we finally announce a new Honeybadger effort: the RailsConf Indie Lounge.
Full Transcript:Starr:
Can I tell you the nerdiest thing that has ever happened to me, that I've ever done? The nerdiest, most embarrassing thing that I've ever done?
Josh:
Sure, as long as this isn't reciprocal.
Starr:
No, it's not reciprocal. It just reminded me of that. When I was in junior high, I was a super big computer nerd. It was the 90s, the mid 90s, so that wasn't cool back then. It wasn't seen as some sort of path to fame, riches, or anything. There was a song, it was really popular, I think it was by INXS and it was called More Than Words. It's this really sweet love song, something about my love can't be expressed by words and I was like "this is how I feel about my computer."
Ben:
Nice.
Starr:
See, I'm editing the show this week so I feel safe. I feel safe disclosing that because I can just edit it out if I want to.
Josh:
And you were listening to this on, what would it have been, CD probably?
Starr:
The radio.
Josh:
The radio? Wow.
Starr:
No, the radio. Yeah.
Josh:
When did we switch from cassette tapes to CDs? I don't remember.
Starr:
It was around that time. There were definitely still cassettes around. People still had cassette players.
Josh:
Yeah, but definitely wouldn't have been MP3 downloaded from anonymous FTP server or something. That feels like five years later.
Starr:
Yeah. I don't know what you're talking about. Are you from the future, Josh? Are you some spaceman from the future?
Josh:
I am, actually.
Starr:
Okay. So, we didn't fully discuss it but we discussed it in chat a little bit, talking about sort of what's been going on. It's been a pretty eventful week, we've shipped a lot of stuff, we've had some stuff happening on the job search front. Is that what you guys would like to do?
Josh:
Works for me, if that works for Ben.
Ben:
Sure.
Starr:
Okay. What should we start with?
Ben:
Let's start with the most boring part of the week.
Starr:
Oh, really?
Ben:
Yes. That was the most of my week, which was writing policies.
Starr:
Yeah?
Ben:
Yeah.
Starr:
I'm sorry. You seemed a little bit low energy too. That makes sense now.
Josh:
It's funny because the most boring part of my week was reading Ben's policies.
Starr:
Oh. Sick burn.
Josh:
Ouch. Sorry.
Starr:
So, what are these policies and why are you losing so much of your life force working on them?
Ben:
We are working on Site2 compliance. We have customers who would like to get our Site2 report and we don't currently have one. We'd like to have one because all the cool kids have one. The idea being that a Site2 audit gives you the stamp of approval that you're running your business in a way that's secure and does things that big boy businesses do, I guess. A lot of part of the compliance is, you have to define how you run your business through policies and then the auditor comes and checks that you're actually running your business like you say you are. We have a lot of things that we do at Honeybadger just because that's the way we've always done them, that's our MO, but this is actually documenting those processes like, how do we select a vendor? We actually do care that our vendors have security policies and we follow up on that. All these policies that I'm writing and getting done, basically just put into words exactly how we run our business.
Josh:
Yeah and we're mostly doing this so we can work with customers that require this, right? I think we've been finding that it has been a helpful process to actually go through and document these things just for the sake of having it. It makes us think about how we do things.
Ben:
It's a good feeling. It's a good corporate hygiene and it's nice to be able to say, yes this is what we believe at Honeybadger and we're putting our signature on the line saying this is actually what we're doing.
Starr:
I feel like in early years it would've been a much more simple policy document. It just would've been like, I do what I want.
Josh:
Just shrug.
Starr:
Yeah. Whatever.
Josh:
The shrug emoji didn't exist back then but it would've been the ascii version, or whatever.
Starr:
Yeah.
Josh:
The text one.
Starr:
Oh, that's too complicated. You have to use lots of characters to make that one.
Josh:
You can figure it out.
Starr:
No, I can't.
Ben:
Just use /shrug in Slack.
Josh:
Yeah, well. This is probably before Slack though. Campfire, maybe.
Starr:
Yeah, so...
Josh:
Sorry, Ben, I didn't mean to say that I was bored out of my mind with your documents.
Ben:
That's totally fine.
Josh:
To be honest, it's not your first choice in reading, I would imagine, for anyone but I think it has been enlightening in any case to learn some of these large business practices and terms that we're not typically exposed to. And if all the cool kids do this and all the cool kids are rich, then we definitely want to be like the cool kids.
Ben:
Definitely. The thing that's been interesting, though, as I've sat back and looked at some of these things and in light of the hiring that we're doing right now, it is useful to have all these things on hand for the new person that shows up. For example, one of the policies this week is the Change Management policy, which defines how we do software development at Honeybadger. We've always said it's a pretty loose process. We're pretty independent and that sort of thing but we actually do have some controls in place to make sure that we don't put bad code in production.
Ben:
We do pool requests and we do require someone else to review big changes and we do have automated CI/CD. We do have a way to revert changes, right? So, all of these little bits of how we do business are now documented and when a new hire shows up, it'll be easy to point that person at a document and say here's your 30 second introduction to how we do things at Honeybadger.
Josh:
Nice. We could probably also summarize or copy some of this stuff into our handbook then smooth over some of the legalese areas. We probably don't want to just send them to all of our compliance documents. It would be like, okay your first week is also reading our compliance documents from start to finish.
Starr:
Yeah, and you know we'd have to quiz them on it to make sure they actually read them. Otherwise, nobody would really read them.
Josh:
We could have an 80 question, multiple choice quiz on each document.
Starr:
There you go.
Ben:
Well, I mean, there is a policy that says that everyone has to receive these policies and sign off on the handbook and things like that.
Josh:
Yeah. Nice.
Starr:
You know how people are with stuff like that. It's like the terms of service on every software application, that I'm sure we've all read in detail.
Josh:
Yeah. Well we could probably summarize it for the handbook and then link to the long version or something like that too. Just so they receive them.
Starr:
By the way, I'm officially stating that I'm not undermining our policy that all employees have to read the appropriate documents. I'm just being a smart-ass.
Josh:
We'll speed that part up, like they do the small print on radio commercials.
Ben:
Exactly.
Starr:
I thought that guy did that by himself. I thought that was just a guy who talked really fast.
Ben:
Do you remember that Micro Machines guy?
Starr:
Oh my god. The Micro Machines guy! Yeah.
Ben:
Yeah.
Starr:
I forgot about those.
Josh:
I don't remember the Micro...
Ben:
It's before Josh's time, I think, but back in the olden days when they had toy commercials on TV...
Josh:
Which was like six years before your days...
Ben:
There was this toy called Micro Machines, a set of toys. They were these itty bitty cars and planes and stuff.
Josh:
Yeah, I kind of remember those.
Ben:
They had this one particular actor who would read the copy for these ads in a very rapid fire fashion. He also did FedEx ads.
Josh:
Okay.
Starr:
Oh, yeah.
Josh:
I, kind of, vaguely remember those.
Starr:
I've got a fun fact for y'all. Actually there was a time before toy ads were allowed on TV. Yeah, basically it was considered exploitative for a long time, so the FCC disallowed advertising to children, I think, of any kind.
Josh:
So, this would've been before we advertised to children but back then most of them were cigarette commercials.
Ben:
Right?
Starr:
Yeah, basically. Essentially what happened was that Reagan came in and deregulated everything and as part of that, okay we can now advertise stuff to children. That's when all the toy commercials came onboard. This I'm really ambivalent about. This fact I don't really know how to feel about it but cartoons then were developed as elaborate plots to sell toys to children. So, many of my favorite childhood cartoon memories like He-Man and G.I. Joe and all that were, ThunderCats, hello... No, ThunderCats, Ho! That's right. They weren't like ThunderCats, Hello! Anybody there?
Ben:
Voltron?
Starr:
Yeah, were an offshoot of companies trying to sell stuff to kids.
Josh:
It's still like that today.
Starr:
Oh, it totally is. [crosstalk] It's a hell scape out there, Josh.
Josh:
Yeah but I still can't get over the fact that they stopped selling kids cigarettes and alcohol and started selling them toys because that just seems messed up.
Starr:
Oh, totally. Wow. Is there anything more about compliance? I'm trying to figure out... So, out of all this compliance stuff, does that mean that we will be creating new childhood memories for some future generation...of children? Is that the moral of the story?
Ben:
Yes. Yes, it is.
Josh:
That Honeybadger's here for the long term.
Starr:
We're here for the long term.
Josh:
And...if you want to order our Honeybadger action figure, call this number. It's on our website.
Starr:
Yes, we should do that.
Josh:
1-800...I forget our phone number because we never use it. I've answered it like twice...
Starr:
I want an action figure now.
Josh:
In seven years.
Ben:
Speaking of our 800-number, I use it periodically. Just this week I used it when I was signing up for a service. I won't name names, but I was signing up for this B to B service and they asked what's your company name, what's your phone number.
Josh:
I do use it for that.
Ben:
So, I use it. Exactly.
Josh:
I use it as a spam trap.
Ben:
Exactly. Well they got me because after I clicked the sign up button and they took all this info, the next page was we sent you a text message to verify your phone number. Please enter the verification code to complete your sign up process.
Starr:
Not all phone numbers can receive text messages.
Josh:
I was like, well, my entered number can't receive an SMS, so now what do I do?
Starr:
That's just dumb. Business phone systems can't receive text messages.
Josh:
We use Grasshopper, don't we? Grasshopper does. I think they do support SMS on their mobile app but I don't know if they support it for 800-numbers. They do for some though.
Ben:
Well, not ours.
Josh:
Okay.
Ben:
Because I...[crosstalk
00:15:33]
Starr:
People still have landlines. Those exist still. [crosstalk] I don't know why this upsets me so much.
Ben:
Well, it wouldn't have been so bad if on the front page where they took your phone number, they said, oh by the way we're going to text you so that you can complete the sign up process but they didn't. They just said, give me a number and I'm like okay, here's my number.
Josh:
Yeah.
Starr:
Yeah. Lame. That's my rant for you.
Josh:
On the topic of landlines, I am actually in the process of setting up a landline in my house as an experiment. I've been trying to find ways to disconnect from my phone when I want to be away, I want to not be online. That's what I do on vacation and it's great, so why not do that more of the time when I can. But I cannot disconnect because I have this online business that demands if there's an emergency or something, I don't want to be gone all the time. So I'm going to put a landline in my house, connected to pager duty, because they can call you and then I can turn my phone off whenever I want.
Starr:
Whoa.
Josh:
Although, now, the hitch might be that I also get woken up in the middle of the night by spam, by telemarketers, so I'll get back to you both on this. If it works, I'll let you know.
Starr:
Yes, so I'm wondering Josh, how does that work with maps? Do you just get a really long cord and spool it out the back of your car or what?
Josh:
You mean if I need to go somewhere? To navigate somewhere?
Starr:
Yeah.
Josh:
I call the direction service. I forget what three number code that is but you just tell them the address then they give you sight based directions like, turn left at the red building.
Starr:
You're going to have to remember them though.
Josh:
Yeah, I'll just call you.
Starr:
Oh, that's a good idea. Yeah.
Josh:
Yeah.
Starr:
I don't know how to get anywhere. What are you talking about?
Josh:
I'd be like, Starr, how do I get...?
Starr:
What are you talking about? I don't know how to do anything. Okay, so we should get back on topic. What else have we done this week that we want to talk about?
Josh:
This isn't a topic but Basecamp released their new email. The service to solve email that they're kind of been hinting at.
Starr:
Oh, that's right and you're really upset. You're really mad.
Josh:
I'm not mad.
Starr:
You're furious.
Josh:
I know what you're trying to do, Starr. You're trying to raise the heat levels on Founder Quest for the ratings.
Starr:
You know, we've had too much freaking Richard Banner here, I hope I got that name right. We need some more Hulk. Less Banner, more Hulk.
Josh:
They named their product for email. They named it Hey. Meanwhile, I've been working on a product for email named Heya. Oh, and both have a logo that is a waving hand although to be fair, mine is just an emoji. They actually had one of their designers go and trace it.
Starr:
That's not agile. We've got a venerable history of this. Our logo for the first several years of our company was on some lightning bolt icon.
Josh:
We're extremely lazy at Honeybadger.
Starr:
When it comes to logos at least. I don't know.
Josh:
I don't know. I'm pretty [crosstalk]
Starr:
I'm sorry, Josh. I'm sorry if that takes the wind out of your sails a little bit.
Josh:
No. It's fine. I don't know yet if it's actually going to cause any confusion as far as two email things being so similar in name but I did email them because they said email them with a story about email or whatever to get an invite to Hey. I did email them and I promised not to enforce my trademark, if they would give me a Hey account. Fingers crossed but I'm looking forward to joining because it sounds pretty cool. We'll see what they did.
Ben:
I saw on Twitter this morning, they have 12,000 people contact them about getting access.
Josh:
I had the thought that, that might not actually get read.
Ben:
They only have one Joshua Wood.
Josh:
I know that they were just sitting on the edge of their seats just to see if I would notice the similarity in branding. It actually is flattering, to be honest, because we both independently, at the same time in history, came up with the same branding for email.
Ben:
It's got to make you feel good.
Josh:
It feels good. Mine is not quite as large in scope, I have a feeling. I'm sending email sequences, they are solving the email problem on the internet. I've got a [crosstalk] little bit of work to do.
Ben:
Maybe they are avid listeners of Founder Quest and they heard our broadcast about Heya and they're like, you know what that's a great idea.
Starr:
Son of a bitch. You're right.
Josh:
The timing coincides.
Starr:
Okay, we are pulling the cloak down on this, guys. We're putting the velvet curtain back up.
Josh:
I do have to wonder how much they shelled out for Hey.com because that is a freaking bad-ass name and I'm jealous.
Ben:
Yeah, that is totally awesome. It's definitely a far cry from their early days of their company when it was like BasecampHQ.com, right?
Josh:
Yeah.
Starr:
How are people going to know if they're talking about... People might think they're purveyors of hay. You know like to feed cows.
Josh:
Like h-a-y?
Starr:
Yeah. How do you know? It's really dumb business sense. I don't know what Jason Fried was thinking.
Josh:
Hay bales. All those farmers are going to be so confused.
Starr:
They are. Those poor little fellows.
Josh:
All the Google conflicts.
Starr:
All the Google conflicts. I was going to make a joke about rural people, which is okay because I'm kind of from a rural place, but I'm not going to do that because I don't want to be a jerk. I'll do it in private.
Ben:
We did launch, I think, this week. We launched our public dashboard.
Starr:
Yeah, tell us about the public dashboard.
Josh:
We launched our public dashboard, privately.
Starr:
This should've been the first thing we opened with. We just have a pyramid. We need an inverted pyramid, right?
Josh:
We launched a bunch of things this week, it feels like. But public dashboard, I think, is my favorite.
Ben:
Really, you think that's more a favorite then Breadcrumbs? Because that was pretty cool.
Josh:
Breadcrumbs...it is. It's great. Breadcrumbs was a lot of work and I'm happy it's over. I'm happy that it's out there and people can start using it.
Ben:
We need to back up and be like, what are we talking about.
Josh:
Yeah.
Starr:
So...what are public dashboards? Can somebody explain that?
Josh:
I'm just getting there.
Starr:
Get there.
Josh:
Ben built public dashboards so, I want Ben to introduce us.
Ben:
I thought you were going to do it because it was all you. We had our friends over at DEV, they got in touch with Josh and they said, hey-
Josh:
This is DEV. DEV.to.
Ben:
Said we love to be able to... We love Honeybadger. Thanks guys we love you too.
Starr:
Are these customers?
Ben:
Yes.
Josh:
They are.
Starr:
Wait, you mean the leading developer? Like developer blog platform is a Honeybadger customer?
Josh:
The platform that might replace Twitter for developers, which is a sorely needed thing to happen.
Starr:
Huh. Well that's a cool little fact. I didn't know that.
Ben:
Yes, they are super awesome and only partly because they use Honeybadger.
Josh:
Yes.
Ben:
But they love the public sharing ability that we have where you can publish a public view of an error that you get, which is stripped of personally identifiable information so you don't have to reveal all your secrets to the entire world. You can share an error if you want to get some public feedback on, maybe, can someone tell me what this is or whatever? What they asked for was an ability to list all of the public errors that they share with people. Previous to this, you just had to pass around a link but now we have a dashboard where you can go and see all of the errors that DEV has shared with the world. They can have the opensource contributors helping them resolve their errors and I think it's a pretty cool thing.
Starr:
That is so cool.
Josh:
They also have a Honeybadger label on their GitHub project and every error, they also cross post to their GitHub issues and give it a Honeybadger label. Which, I think, is just awesome because you can go and see all the errors and see how they link to us.
Starr:
That's so awesome. I love the idea that there's this whole, sort of, community out there working on this project, this platform, and we are providing, sort of, a very useful service to them. Bringing people together because I always hoped that, that's what we would do as a company is bring people together.
Josh:
Right.
Starr:
That's why, with you guys, I started an error monitoring service.
Josh:
This was the long term plan.
Starr:
This is the long game.
Josh:
Yeah. So, DEV published a blog post about this and how they're using it and we'll link that up in the show notes. We have not actually publicly released this feature yet. We will be soon, as soon as we have a setting to turn it on and off but the hope is that other open source communities... So, Honeybadger is free for nonprofit, not for profit open source. Obviously any other open source projects, that are for profit, can use it as well but a lot of these projects don't actually host their applications, they're just open source software code that maybe someone else hosts but some do.
Josh:
DEV is an example of one that does. RubyGems.org is another that uses us and also runs the RubyGems.org servers, which is why they use us. I'm hoping that there are some more of these types of projects, that are open source out there, that does host things can get some use out of this where they can share the dashboard with their community and it'll give them another place to involve people and they can fix errors together.
Josh:
Can I tell you a cool story about Ben though?
Starr:
You should ask Ben that, I guess?
Ben:
No. Just kidding. Yes, of course.
Josh:
Molly over at DEV, she emailed me about wanting something... She came up with the idea, basically, for the dashboard. Thanks Molly.
Starr:
Thank you Molly.
Ben:
Thanks Molly.
Josh:
She emailed me, I think it was in January or something because it was before we had our all-hands meeting with everyone. I was like, I love that idea, we're going to talk about that so we talked about it at the all-hands meeting and agreed that it's a cool idea we should do it to support her. That's, kind of, how we do our quarterly planning. And so, after the meeting, the week or something after, I was looking at all my projects that I had to do for the quarter. I'm like, these are all really awesome projects and I want to do all of them but I don't think I'm going to be able to personally do them all.
Josh:
So I put up a few of them, I was like. Hey, does anyone want to help out with some of these so that we can get them all done together? Ben volunteered to do the public dashboard project, which I was like. Great because that was one of my favorite ones. I wanted to get it done. The next day he deployed it. It turns out that that one was actually like, I was thinking, this is going to take me at least a week. I'm going to have to think about this and get it all planned out and stuff and Ben just busted out and throws it on a branch and then it's deployed. I sent it to the DEV crew like a couple of days later. So, thanks Ben.
Ben:
Fun times at Honeybadger. I always love it when I can do that.
Starr:
I feel like that's an archetypal Ben story.
Ben:
It's great.
Josh:
Yeah.
Starr:
So... Breadcrumbs.
Josh:
Breadcrumbs. Did we talk about Breadcrumbs before?
Starr:
We did.
Josh:
I thought we did.
Starr:
We talked about them.
Josh:
When we [crosstalk] launched it for Ruby.
Starr:
When we shipped them as part of the main product.
Josh:
Yeah. We can, kind of, just describe what they are. What we launched this week was Breadcrumbs for JavaScript. Clients at JavaScript. So we're bringing Breadcrumbs, which we had launched. We had added to the product and we launched them for Ruby last year, and then we added them to Elixir, and now we're finally getting around to adding them to JavaScript. I feel like, this is their sweet spot actually. Most people actually want them or use them for JavaScript. They're extremely useful. What they are, are like basically an event log that is recorded all the time as your users interact with your application. So it might be your actual application logs, like in a Rails app, events that happen like active support events and stuff we can instrument in the browser for the client side. Think of things like consul logs, clicks, ajax requests and all of that sort of stuff that happens as your user's interacting with your application.
Josh:
Breadcrumbs basically log those events and then when an error happens it sends all those events, that event log or a chunk of it, with the exception report so you can see what the user was doing and what happened before the error occurred. Which is extremely useful on JavaScript because JavaScript is a little flaky on providing context around errors. Especially in asynchronous callbacks or things where it's outside of the users direct involvement, it can be really difficult to trace it back to a user action and say this is what caused this error. This should really help people reproduce exceptions or errors that happen in there and react and review applications and that sort of stuff.
Starr:
And, also, it's going to be super useful because a lot of JavaScript errors are just completely bad. They don't give you enough information to figure out what exactly happened. It's just like, something went wrong. Okay great, thank you JavaScript.
Josh:
Starr, it's a script error happened.
Starr:
Oh, it's the script error. Oh, it's a script error. Sorry.
Josh:
Come on, Starr.
Starr:
Sorry, I didn't mean to be such a prima donna.
Josh:
Starr, there was an error in your script. Obviously, there's an error in your script. Just go fix it.
Starr:
Oh, my script. Oh, sure. It's only, what...
Josh:
It was on line one. It was line [crosstalk]
Starr:
3,000 lines of code?
Josh:
Column like 500,012.
Starr:
Oh my gosh. Why do they even have errors in JavaScripts? Why do they even bother?
Josh:
Yeah.
Starr:
I don't know. Anyways but the thing is Breadcrumbs is now useful.
Josh:
Yes. It's true. JavaScript errors are terrible, for a lot of reasons, but the biggest ones are this issue we're talking about. Not being able to trace them across...connect them to user actions and then also the minification that happens when you build your code and compile it to reduce file sizes and make it optimized for the web. It cuts a lot of your source code out. You don't actually know where the error is in your source code and you fix that with source maps. Source maps are the answer to that but, again, it's an extra complicating step that just makes it all really difficult.
Starr:
Even with source maps it doesn't always...it doesn't give...it's not 100% solution. And with the Breadcrumbs... I'm thinking of some errors I have troubleshot in the past where there was just no information given to fix it. Breadcrumbs wouldn't have told me exactly what was happening, necessarily, right away but it would've told me what I need to do to reproduce it in a browser so then can go and do it myself and see what was happening.
Josh:
Yeah.
Starr:
That's huge.
Josh:
Yep, I'm excited. I was actually looking at one of our own front-end errors because we use Honeybadger to monitor Honeybadger. We had an error in our front-end UI on our main Honeybadger app, which is a Rails app that uses Webpacker and that whole Stack, but yeah I was looking at this error report, I'm like. That is a really good looking JavaScript error report. It tells me what the problem is. It tells me exactly where the code is. It linked to the source code on GitHub so I click through like it's the-
Starr:
That's a good feeling.
Josh:
It's the Honeybadger workflow that we're familiar with for Ruby, for JavaScript, which kind of blew my mind, to be honest, because this has been such a disparity in the past. I think we're starting to get good.
Ben:
You reminded me of that Saturday Night Live skit from several years ago, the Handsome Man skit series? You are a handsome man into you are a handsome error.
Josh:
Nice.
Starr:
Sometimes it's the best feeling because usually when I come across work I did in the past, sometimes, you're like "oh, okay what was I thinking" but then sometimes I come across something that I was responsible for and I was just like, "This is really good! Whoa, that's impressive! I didn't know I could do that." It seems like maybe you had a little bit of a moment like that.
Josh:
I did. It felt great because this has been a lot of freaking work. I've been working on this for like three years or more.
Starr:
Yeah.
Josh:
Probably longer. JavaScript has been a relatively large amount of time to get it to this point then one of the backend languages for all those reasons. It takes a lot of work to build these tools that are so necessary to actually get some value out of it so I'm really happy that we are finally starting to see some of that value.
Starr:
We are about to plow into the JavaScript market like a ravenous honey badger.
Josh:
Maybe. In any case, for modern Rails development it's really nice too because if you do Rails new today, you get a Webpack pipeline. You can basically just plug in our Honeybadger Webpack, NPM package and whatever, they use yarn, right? Yarn install.
Starr:
Yeah.
Josh:
That gives you automatic source maps. Now, if you ever try to get source maps in the old asset pipeline, like with sprockets, you'd probably pull all your hair out. I know I did. So, this is a big deal. Being able to just Rails new and get source maps for your JavaScript, I think you can even test your JavaScript in Rails now. I'll stop now. I don't want to Rail too hard.
Starr:
You don't want to Rail too hard again sprockets? Oh, man. Yeah, sprockets has never got the love that it needed.
Josh:
I liked parts of it but...yeah. There's just...
Starr:
I remember hating it when it came out and then I eventually came to an easy peace with it until modern JavaScript happened. Suddenly we needed source maps and everything and it was like oh, okay this is...
Josh:
Sprockets just wasn't built for the modern, it wasn't built for the NPM ecosystem. It was its main problem I think. It was built for the ecosystem where you download a jQuery plug in off the internet and put it in a folder, basically.
Starr:
That'll come back. It all comes back. I miss those days.
Josh:
Right? I mean, it was simpler in some regards.
Ben:
Global objects.[crosstalk
00:38:20]
Josh:
Right?
Starr:
I'm not sure. Oh, god. Oh, no. Okay. I'm going to need some space to process these emotions I'm having. I'm remembering all that. Can I brag about something?
Ben:
Please.
Josh:
Yes.
Starr:
I just want to brag about my writers or my authors. If you've listened to the podcast for any amount of time you'd known that, a while ago, we started soliciting third party authors to do stuff for our blog. That's simply because we really like to put out a certain type of content on our blog, a certain type of content that sort of goes into depth around the issues in, sort of, I don't know, environment surrounding code, not just like how to build a to do app, how to...whatever.
Starr:
Our ability to do that has, sort of, always been limited by just, us, not having time. Even when I've done it myself, I just run out of stuff that I know about, that I can write about convincingly, and so then I have to start learning stuff to write about it. It just becomes very shallow, very quickly. And so, we started bringing on these third party authors and I just have to say I am just so freaking proud of the work they're doing. They're doing such a great job.
Starr:
We recently started publishing all these articles that have been, sort of... I've been hoarding them like some sort of dragon because I just hadn't really figured out what to do with them. I don't know. Maybe I was a little bit scared to start publishing them because I didn't want to waste them because they were so good. I didn't want to just throw them out there and have them fail. But, we've released two of them so far. The first one by Jose, and the second one recently by Julie. They've done so well. They both were placed really highly in Ruby weekly. They both are getting shared a lot.
Josh:
Mm-hmm (affirmative). They did well on Reddit.
Starr:
Yeah, they did well on Reddit. People are giving them lots of love and it just makes me so happy to see them so well received because I really think they're doing a great job. We've got more in the works and more authors even who I'm not naming now because it would just take too long but we have so many people doing such great work for us.
Josh:
I'm really excited about all this. I think it's really cool and also it seems to be more fun to promote other people versus always just promoting yourself. I really like the aspect of, we can give other people an opportunity to write and have a voice and we can, kind of, just be in the background and try to get people to read it. Get it out to our members.
Starr:
I know, personally, this may just be a mental thing of mine but it is really hard for me to be a hype person for my own content because I just feel like a jerk saying how great I am and stuff. Which, I mean, is true but I don't have to say it but you know other people, it's weird-
Josh:
That's why I deleted my Twitter account.
Starr:
Yeah. It just feels really nice to help promote people who I really believe are doing good work and, honestly, who are in a lot of cases developers and they may have the similar feelings about self promotion that I do. So maybe I'm helping them get a bigger audience than they would have otherwise. It just feels really nice.
Josh:
We should also mention that you're paying them.
Starr:
Oh yeah. We're paying them.
Josh:
You're paying them well which is...that's the best part because like, who does that?
Starr:
Apparently people don't pay blog authors?
Josh:
Right.
Starr:
Somebody posted a tweet, they were like, well if you're wondering how much technical authors make, this is how much. I guess a book they wrote recently came out from a major publisher, a major technical publisher, and it was about a very mainstream topic. I think, React or something and like the royalty check from one quarter was like $800 dollars. We have been paying...
Josh:
Isn't that our minimum...?
Starr:
No, we've been paying around $500 dollars, but for an article. Not a full technical book.
Josh:
Right and isn't that the minimum, we don't pay someone less than $500.
Starr:
Yes, that's the minimum. So far we haven't gone above it but if somebody wants to really tackle a super complex thing and they're just like it's going to take me too much time, I would totally talk to them about that.
Josh:
Yeah. I just think that's great.
Starr:
Yeah, I don't know. It feels like I'm going some good in the world. Finally, we wanted to talk about... Do we want to talk about hiring and how that's going?
Ben:
Yeah, when Josh was talking about Breadcrumbs and how much time it took to get there, I was thinking, with the hire we're working on now, that would be very helpful in getting that kind of stuff done a little faster because the goal is to have someone that can really own those libraries and bring them to where we want them to be because they're just not. I mean, they're great, but they're not where we want them to be yet. Having someone on board to help with that. As I've been talking, I've been doing that this week along with writing compliance, so the more interesting part of the stuff I've been doing is talking to job candidates which has been fantastic. I always love doing that, it's energizing because there are so many awesome people out there who are doing so many awesome things.
Ben:
Talking with them about taking on this responsibility of, not only JavaScript but also writing some Elixir code and some Go code and whatever else we're supporting, but also owning parts of the Rails app. It's been fun talking to developers who are in a variety of situations and talking to them about our process because so many developers are in the conveyor belt software development world. I call it the conveyor belt, you have some sort of project manager who's writing specs and the specs show up on your desk and then you write some code to meet the spec. You ship that code and you turn around and there's another set of specs on your desk, right? So it's just this like conveyor belt of things you're taking off the conveyor belt, you're writing code to put back on the conveyor belt, and it sucks.
Josh:
Yeah.
Starr:
Can we call that like jera driven development?
Ben:
Yeah, I like jera driven development...
Josh:
JDD. You're probably not even integrating that code, right, like in a lot of cases?
Ben:
Yeah, depending on the size of your company.
Josh:
Someone else could be. If it's really large, someone else could be stitching it together.
Ben:
Right. So it's been fun talking to people and helping them understand we don't work that way at Honeybadger. We own our projects. We pick something we want to work on because it's always a question. Whenever I ask the candidate what questions do you have for me, a question that always comes up is, how do you schedule work? How do you pick projects? What's your roadmap and stuff like that. I always explain it's really about whatever interests you. We have a list of things we want to do.
Josh:
What roadmap?
Ben:
Exactly. I always say that. Well we don't do a roadmap. We do have goals but out of those goals we have project, tasks, and wishlist items and all that kind of stuff. Basically you sit down and when you have some time you say, what do you want to do? And you pick something and you go and do it and you own that and you build it from start to finish. It's fun talking to developers and just see that gleam in their eyes like oh, that sounds like heaven. Like yes, it is.
Starr:
I can see certain ways that sort of having everything specked out and just focusing on this narrow aspect of things might be good. If you have a certain type of outlook or whatever and yeah, we're not saying that's necessarily bad or anything, it's just we have a different way of working because we just don't have people that can write specs all day.
Josh:
You know what we do? We kind of treat every project like a side project almost. You're going to go start this thing, you're going to figure out how to even do it first because it's you. It's all you. And then you're going to build it and what you build might be the first version and if it really becomes a central piece of Honeybadger, we might rebuild it in the future or enhance it but we don't architect for some massive scale initially. We kind of build everything like we initially built Honeybadger, which was, let's just build this Rails app and throw it on a dinky server and see what happens.
Starr:
Except we don't have dinky servers anymore.
Josh:
They're not anymore but we certainly did.
Starr:
So, all this seems to relate back to the fact that we all started out in life as freelancers so we're all very comfortable with that model where it's like, okay. I'm just assigned this big objective and I'm just going to go away for a while and work on it. I think maybe people don't fully understand that about us sometimes because when we are talking about being polyglot or knowing these different languages and stuff, we're not really talking about now you're going to be specked out to build this little feature in Go. Now you're got to switch to Ruby. Now you're got to do this other thing over here in JavaScript. It's more like, here's this objective, it involves some stuff involving JavaScript or whatever. So yeah, you're going to be working in JavaScript for a while. When that's done maybe it'll be some other objective and maybe that involves Ruby so you get to sort of immerse for a while in that. So it's not like you're constantly switching back and forth like every hour. It's just like a project mentality.
Josh:
I think we're figuring out a lot of this out. Not only process but hiring and all of this stuff but I have a feeling that we tend to gravitate towards what we like. People kind of choose what they like to work on for the most part, right? If you're owning part of the app and you really like that part, which is how you ended up there, we're not going to say, oh now you have to learn a different language and do that now because this fun part is over. I think people gravitate towards areas of the company where they're going to make the biggest difference. I don't know. This is just kind of a thought that just came to me but, I don't know, maybe our job positions morph over time too. Does that make sense?
Ben:
Yeah, definitely.
Starr:
Makes sense to me. We're the Mighty Morphin' Honeybadgers.
Josh:
We're like a transformer.
Starr:
Like Voltron.
Josh:
Yeah.
Ben:
Back to the cartoons. It's always back to the cartoons. Actually speaking of cartoons, as you were talking about how we do things in our process, I was thinking about Dilbert cartoon. I can't remember when it aired but it was very short run. There was actually an animated cartoon series for Dilbert.
Starr:
Oh yeah. I remember seeing that when I worked in DC.
Ben:
There was this episode, at least one maybe more than one, about Nirvana Co. Thing was, Dilbert's office is terrible, everything bad that could happen to you as an engineer happens at Dilbert's office, right? But Nirvana Co was the very opposite. All the engineers wanted to work there because they had these beautiful projects and this awesome process and everyone is just happy. Then it becomes destroyed as they try to bring in some process that Dilbert's like, you mean you don't do x, y, or z? They're like, we've never heard of that let's try that and he's like no, no, no. The episode ends with Nirvana Co is completely destroyed.
Josh:
It's like the ideas coming in wreak havoc.
Ben:
So yeah, we're trying to copy Nirvana Co.
Josh:
We're trying to keep bad ideas out.
Ben:
Right. Make it an engineer's paradise.
Josh:
One of the things Ben and I worked on, mostly Ben, the past week or so was rewriting the job post because our initial one, we had some feedback from people and we realized that it was very fact based, factually oriented like here's what we're looking for, here is what you do. It talked a little bit about us and our process but from a standpoint of selling this position, I think it came across as this is a lot of different responsibilities. There's a lot of different things in here, I think the polyglot stuff in there might have been part of that, but we ended up rewriting it to focus a little bit more on the whole position at Honeybadger. Which kind of fits into our culture and how we work too. Because like you were saying, a lot of people don't get that part of it unless we explain it. So we realized we need to always be explaining that part of us because it's so different from what people are used to.
Ben:
Yeah, I don't think there was anything wrong with the original post but I think if you were coming to that job posting in the same mindset that you would come to a job posting at Amazon or something, you'd be like oh crap this is a lot. If you understand that we don't really work like that and you understand the whole context then it makes a lot more sense and it's a lot more reasonable.
Josh:
Yeah. It's really just a matter of framing. We made a few other tweaks, I think, to it. We had a salary number posted in that one too.
Ben:
And the updated listing I also put in a bit about how they're be also working on our main app. That was completely left out of our original. Some people thought, oh I'm just going to be working on the client libraries, that seems kind of boring, right? But no, that's not what we're going to be doing 100% with this job, it's going to be working on other projects and the new products that are coming out this year.
Starr:
Well, in interviews, well I mean, Ben's already started the interviews but the rest of us are going to get in on the action next week. So, I'm super excited about that and talking with people.
Josh:
That'll be fun.
Starr:
And seeing what they have to bring to the table for the Badger.
Josh:
Yeah.
Starr:
I'm not going to talk to them like that don't worry.
Josh:
See if they're willing to put on a badger suit.
Ben:
Right, still have to get someone to put on the badger suit.
Starr:
Yeah.
Josh:
I think Ben Findley is still hot on that. I think the only thing that's stopping him is us.
Starr:
Let me ask you guys. Is the RailsConf thing a sure deal at this point?
Ben:
Yes. It is a sure deal.
Starr:
Okay well, we will be having a...what is it, a lounge?
Ben:
Yes.
Starr:
We'll be having our own lounge at RailsConf and probably with some other great companies that we are going to be working with. Some Indie companies and so maybe there'll be a badger suit there.
Ben:
Well, I would say that if you are an Indie company like us and you want to hang out in the Honeybadger lounge with us, please get in touch. We're doing co-sponsoring, we're allowing the opportunity for other people like us to join with us in having this space at RailsConf. If you're part of the Rails community, if you're a small Indie start up, come talk to us.
Starr:
We should do another episode where we talk about this a lot more.
Josh:
We should.
Starr:
That would be so interesting.
Josh:
We should do it next week. I think the actual title is, I think we're calling this the Honeybadger Indie Lounge.
Starr:
Yeah.
Josh:
So this is the purpose of it and we should really talk about it.
Ben:
Okay, let me just say this. First of all, we've made it in life. We're rolling with the big dogs and whatnot but for a long time we were not quite there yet and we always felt excluded from places like RailsConf, just because they're so expensive to get any sort of sponsorship deal there. Now that we're sort of able to do that, we are trying to bring in a community of Indie creators and help open up that space to people who might not otherwise be able to access it.
Josh:
That's a perfect description of it.
Starr:
You're freaking amazing.
Josh:
Good job Ben.
Starr:
All right. Next week. We'll leave on a cliffhanger.
Ben:
To be continued.
Josh:
If it's not next week, it will probably be one of these weeks.
Starr:
Yeah. Should we wrap it up, you have anything else you'd like to add?
Ben:
Let's wrap.
Josh:
That's a wrap.
Starr:
Okay. That sounds great. I talked a little bit about hiring writers and so if you would like to write for us about, preferably Ruby, it'd be cool to get some Elixir authors. I would like to see some Elixir content. Yeah, stuff like that. Just go to our website. Go to our blog and you'll see a 'write for us' link in the top nav and if you're interested in a career with us, interested in applying for this job, it might be filled by the time this goes out but who knows. There's a link in the footer of our website called Jobs or something.
Starr:
Yeah, other than that. I'm just going to beg for you to go give us positive reviews places because this is what we do. I don't know. Do we really need positive reviews?
Josh:
Honeybadger doesn't care so...
Starr:
Yeah. I think my own validation comes from inside of myself. I don't think I really personally need them but if people want to give them that's cool
Ben:
Or you know, if you want to come write compliance policies for me, feel free to.
Josh:
Is that our next hire?
Starr:
If you want to write compliance policies, if you want some fascinating reading material...
Josh:
You can handle our year-end taxes.
Starr:
Yeah. I need someone to tidy up my office.
Ben:
All kinds of opportunity here at Honeybadger.
Starr:
Yeah, we're just saving the world, one error at a time. All right. See you guys later.
Josh:
Bye.
S2E17