Subscribe
Share
Share
Embed
Software engineering is getting weirder by the week. AI is reshaping how teams work, processes are breaking, and org tension is real - and the best lessons aren't coming from keynote stages or polished LinkedIn posts.
The Hallway Track is a podcast for engineering leaders who are building teams, navigating complexity, and looking for ideas that sound like the world they actually live in. Real stories from real teams. No recycled FAANG playbooks. Just honest conversations with the people in the trenches - about what's changing, what's breaking, and what's actually working today.
Hosted by Chris Vannoy, founder of Axiomatic Consulting and a 20-year veteran of software teams at startups, agencies, and B2B SaaS companies. New episodes every other week.
Connect with Chris: https://www.linkedin.com/in/cvannoy/
Learn more about Axiomatic: https://getaxiomatic.com/
Patrick Byrne (00:00):
One thing that I have really been advocating even before I was an engineering leader was engineers being more involved earlier in the process because people don't know what's easy and what's hard. They don't necessarily know what they want and they will sometimes self-censor. Pushing that earlier in the process helps avoid getting to the end and that's actually not what we wanted at all.
Chris Vannoy (00:23):
Welcome to The Hallway Track. I'm Chris Vannoy. This week I'm sitting down with Patrick Byrne, vice president of engineering at Dribbble. That's with three Bs. Pat's been running engineering there and on a 17-year old rails monolith through every process trend of the last decade. They've gone from strict sprints to rigid gating, multiple rewrites of the how we work doc and he and his team have landed back almost exactly where they started at the very beginning. We get into why is team rejected formal process like a virus, what hiring for judgment actually looks like in this day and age and why he wants every senior candidate to tell him about a time they took down production. If you've ever bolted on process to solve a real problem, then watch that proces become the next problem. This episode's for you. Hiding folks. Welcome to the hallway track.
(01:15):
My guest today is Patrick Byrne, the vice president of engineering at Dribbble. Howdy, Patrick, how you doing today?
Patrick Byrne (01:22):
I'm doing pretty fantastic. How are you doing?
Chris Vannoy (01:24):
I am fan freaking tastic as well. Patrick and I have known each other for quite some time now. We both have a background long ago in newspapers and journalism and all sorts of fun stuff like that. But that's not why we're here today just to reminisce. So why don't you let folks know what you're doing today at Dribbble and kind of what Dribbble is for those who don't know the very few people on the internet who don't know.
Patrick Byrne (01:46):
Absolutely. Dribbble.com. It's a social network for graphic designers to share their work, get inspired by the work that other people are doing, but also maybe more importantly to also get hired and find other designers to work with and work for. Either get hired full-time design gig at some company or to or doing partim work on their side or full-time contract work for clients. Anywhere you want to want to do to, if you're doing graphic design, if you want to be seen, you want to see other people, triple.com with 3Bs.
Chris Vannoy (02:14):
What's engineering look like at Dribbble today?
Patrick Byrne (02:17):
Yeah, it's a pretty small team and Dribbble.com is a Rails monolith that is now over 17 years old. And so it's been through its fair share of the ins and outs and ups and downs of Rails and Ruby. Like I said, it's a small team, three front end engineers, three backend engineers and me who I've got my hands in the code with a backend engineering and infrastructure background. They couldn't keep me out if they tried. So we're working on continuing to build and evolve the site and working in a pretty structureless environment actually with a couple folks on the product team and working not really in sprints so much, kind of taking a lot of the lowercase A agile best ideas and really working with engineers really tight in the loop on product design, product decisions and so on and really, really deeply integrated on kind of like a continuous ... I guess if I could think of a word to describe, it would probably be continuous delivery is the closest where we're working in tiny increments.
(03:19):
So it's the smallest change that we can make to rolling out dozen deploys a day, slowly incrementing the product forward.
Chris Vannoy (03:27):
Oh, cool. Well, I got lots of questions about logistics of that. But before we get that, has it always worked that way or did you sort of evolve into this over time?
Patrick Byrne (03:36):
We've absolutely evolved into this. When I joined, it was a team of five folks and everybody was touching the code at some point in the other. This was, I think, before GitHub pull requests were really a thing perhaps, or at least very early days. And then it was pretty loosey goosey. Over the years, we've grown and shrunk as a team. At one point we had, I think, at least a dozen folks kind of dedicated working on joble.com on a daily basis. And so you feel the growing pains, you feel the pains of change as the teams change and as the culture changes and evolve. We've tried adding a lot of process at various points of the way. We were doing really strict sprints at one point and we ended up rejecting that after experiencing quite a bit of friction. Like a
Chris Vannoy (04:27):
Body rejecting a virus?
Patrick Byrne (04:28):
Body rejecting the virus is we were finding ourselves working for the process rather than the process helping support us to do the work. And we've had, can't think of how many versions of how we make Dribbble document in our documentation of various degrees of formality over the years adding layers of review, adding dedicated specified time for planning, implementation, QA, very firmly gating those processes. And ultimately we ended up almost pretty close to the way things were at the beginning now that we're a smaller team again as well where it's a very trust-based system and it's a very much you own your work system where everyone kind of controls what it is that they're doing and they're the arbiter of, is this good enough to deploy outside of QA and if it's user facing, we maybe have a little bit more input from, it doesn't go live until product says it's ready to go.
(05:30):
But like at a code level, at a PR level, is the code reviewed? Are the tests passing? Do we feel confident in the ability? And then you're the one that deploys your own work and if it goes poorly, if there's an error or a small error that you could fix or a larger catastrophic error that naturally we need to pull that back, that's you too. And it's quite a bit of responsibility for such a large site, such a site with a
Chris Vannoy (05:56):
Large- That's what I was going to mention.
Patrick Byrne (05:59):
Yeah.
Chris Vannoy (05:59):
Yeah. It's a little bit interesting because the workflow you're describing as sort of like what Dribbble started as, right? And then you went much more rigid and more process and everything else and then reverting back to what was at the beginning where at the beginning you don't have a lot of traffic, you don't have a lot of downside risk, right? A site goes down and no one's going to care. If the site goes down tomorrow, people are going to care, right? Yeah. So it's interesting, what did you have to do to be able to get that sort of process back or I'm going to say lack of process, but it's not really a lack of process. There's a process there, right? How did you get back to that?
Patrick Byrne (06:39):
That's a good question. And I think there were kind of two different ways that ended up happening. One were the very large breaks where we at a retro or at just an ad hoc meeting that we feel was necessary kind of looking back and say, "Hey, that didn't go great. What's up?" An important part of that is building a safe team for people to feel comfortable to say what is on their mind and that's where a lot of times I was hamstrung by this, that, the other, I didn't feel comfortable doing whatever and really realizing that, oh, this framework that we'd built that we'd kind of grown over the years to respond to prior pain was actually causing its own pain. And there have been a couple of times where we just took a sledgehammer too and we're like, "Screw it. We're starting with a blank sheet of paper.
(07:30):
How should we do this? " Those are very few and far between. What is much more common are we have kind of what we call like a mini retro because it's standup every Friday. We take a couple of minutes and ask what went well last week, what went less well last week? And from that, are there things that we should do more of? Are there things we should do less of? What could we try differently? And that's where I think the real work is of the much like we're kind of slowly iterating on the app, changing and evolving it, adding things, removing things, refining things. We're doing the same with the process of this slowed down because I couldn't get code review. Hey, GitHub can send Slack reminders to, "Hey, these are the PRs that need code review." Oh, going back to the maybe the code review is, if it needs to be out now, don't move on to the next thing while you're waiting for code review.
(08:22):
Just drop in the product channel. I need code review here. Who's available to take a look at it? And really being the advocate for your own work. I don't know why I'm talking about code review. That's not even a problem that we really have anymore.
Chris Vannoy (08:33):
It's code review is the thing that everybody that's suddenly adopting all these AI workflows and it's like, "Well, we could produce code like crazy now, but nobody has time to code review." And so they end up blaming it for the bottom ark. Yeah. Well, it's really the approach I took lots of times when I was leading engineering teams is saying whatever is closest to production has the most priority. So code review has more priority than writing new code because that's something that's closer to production or something that's on the testing environment, your job is to get it off that testing environment as fast as you can. You're taking a valuable space in a lot of cases to get it out the door and keep the train running, right?
Patrick Byrne (09:10):
Exactly. I mentioned before, how can we build this to this in the smallest possible increments that came out of years of merging giant branches that have been alive for two months and dealing with the inevitable nonsense that comes there of, well, how can we make it smaller? How can we ship part of this? How can we ship something that is maybe not user visible and make it user visible later, either through feature gates or building the backend and then building the front end and just like, how can we turn this 100 line PR into five 20 line PRs?
Chris Vannoy (09:46):
Yeah. And 100 line PR always has multiple ... You covered over a lot of stuff with the nonsense. A, code review is never going to catch everything. That's true even at a one line PR sometimes, you're not going to catch everything that's going to go wrong and especially in a hundred lines. So you're going to end up pushing bugs to production in a lot of cases, or you're going to have so much time spent in code review that it takes forever to get out the door. And then when it does, you're still going to have bugs in it no matter how long you took.
Patrick Byrne (10:14):
Exactly.You could spend weeks on QA and still not catch the bugs that our users are going to immediately find by typing in an email address that's a thousand characters long. And you didn't think about that, did you?
Chris Vannoy (10:24):
Yeah. Well, especially at your scale, you've got the millions of monkeys on the millions of typewriters problem of like every edge case you can think of somebody will find.
Patrick Byrne (10:35):
Exactly. Got a flurry of errors in our error tracker this morning that lit up Slack and me and another engineer looked at it like, "Oh dang, thought maybe it was related to something that shipped that morning or something shipped yesterday." No, it was a penetration tester just sending garbage payloads to various things and we were expecting this to be a string and it was an array and so the backend rejected it. The hacker didn't get in, but it did trigger an exception that there's no downcase method on arrays. Okay.
Chris Vannoy (11:12):
Speaking of error tracking, what are you using these days?
Patrick Byrne (11:15):
Honeybadger. Love that stuff.
Chris Vannoy (11:16):
Oh yeah, so do I. I've got a T-shirt in my drawer and stickers on various laptops that are probably just out of screen here, some laptop cover. Yeah, I've always found that super helpful. That's sort of like one of the goals I usually had was finding the error at the same time the customer does so that my team knows at the same time the customer knows. And then our goal was to fix it before that customer can contact customer support because the best thing in the world is when customer support can say, "Try again, we already fixed it. " And it actually makes customers happier. It's like, "Ooh, I helped them out. I've discovered something and got it fixed no
Patrick Byrne (11:54):
Time at all. " It takes a lot of effort to exceed expectations, but when you can, it feels so
Chris Vannoy (11:59):
Good. Yeah, it feels good. And lots of times teams don't have that same sort of error infrastructure where they can get notified immediately. They got to go digging through logs to go find it, which is like, I remember when Honeybadger first came on the Ruby scene a long, long time ago and it really enabled teams I was working with to work just faster. When you can have that visibility into the inevitably broken stuff, right?
Patrick Byrne (12:28):
It's going to write. You simply cannot write bug free code. I've been telling my team to do so for years and it hasn't stuck yet. No. I'm simply accepting that bugs are an inevitable part of writing complex
Chris Vannoy (12:39):
Software. It's one of those things where the phrase I would use lots of times is like the only bug-free code is code you'd never written. It doesn't exist. Every line of code is also a possible bug. So when you start moving into a world where it is, you consider them to be inevitable, you start building systems to recover from it faster because you start to realize no matter how hard you try to prevent it, no matter how much you put in a code review, no matter how much you put in a QA and a testing and anything else, which are all good things, don't get me wrong, do those things. They're good. It's
Patrick Byrne (13:14):
Absolutely critical.
Chris Vannoy (13:16):
Yeah, yeah, yeah. But even once you do all those good things, stuff's still going to get out.
Patrick Byrne (13:23):
Can't think of how many times I've had the conversation of a green build, your tests are passing, all that proves is that your tests are passing. It doesn't prove that the app does what it's supposed to. It doesn't prove that the app is bug free. It just means that the test pass QA passing just means the things we thought to test worked or worked good enough and you don't know until it's out there.
Chris Vannoy (13:46):
The other thing, and I'm curious about how this works at Dribbble is like oftentimes I tended to work with engineering teams with, we baked in two assumptions when we built our process, right? One is the one I just mentioned, assume all the code we're writing has a bug in it somewhere. And the second one was like, we probably aren't building the right thing. We're often working, in my case, lots of what I worked with was like B2B software where we're selling to companies that have a sales team and like that sort of stuff, right?
Patrick Byrne (14:16):
There's
Chris Vannoy (14:16):
Contractual
Patrick Byrne (14:17):
Obligations there.
Chris Vannoy (14:18):
Yeah. Sometimes there's that and there's sometimes the product folks are talking to customers that don't actually know what they want and it's that blank page problem where like if you tell them like, "Oh, what if it did this? " And they get all super excited and like, "Sure, that's great." But then when you put it in front of them, it's like, "No, that's not what I meant at all. "
Patrick Byrne (14:39):
Those questions can be really important. I mentioned before that our engineers are really heavily involved in the product process and that actually is an outcome of some of those other conversations of like what didn't go well there is one thing that I was really been advocating even before I was an engineering leader was engineers being more involved earlier in the process because just like you said, people don't know what's easy and what's hard. They don't necessarily know what they want and they will sometimes self-censor of like, "Well, I'm not going to ask for that because that's too wild," but with an engineer in the room or an engineer very closely thereafter can tell you that like, actually that's easy, that's easy, that's easy. This one little bullet point is 80% of the scope. How important is it? Oh, it's not important at all. Good to know.
(15:28):
If it's critical, then okay, we'll resource for that. Then we will plan for the math that we have to invent for this feature, but pushing that earlier in the process helps avoid getting to the end and that's actually not what we wanted at all. There's nothing more humbling than watching somebody try to use a software like, "We spent so much time making this easy to use. How do you not see that button?" And it's because it's not their job to see the button. It's not their job to know how it works. It's our job to make it easy for them to use
Chris Vannoy (15:56):
It or realizing like, "Oh, people actually do try to tab through forms or not. " Accessibility matters. In some cases. Yeah. Accessibility, that's a whole other ... We only have a half hour today. Let's save that for episode two sometime. We can talk about that. The other thing I'm interested in is a little bit nerdier engineering sort of stuff. It's sort of the evolution of a software engineer where it's like you start your career writing very ... Well, these days, who knows, but you're writing very standard sort of code and then you start getting clever for a little while and since we're both Rubius, you start doing meta programming and stuff like that. And then I think once you do this long enough, you turn back around to writing the very boring stuff all over again. Is that a similar
Patrick Byrne (16:44):
Sort of thing?That's been precisely my trajectory. I've been writing Ruby since before Rails came out. I remember being very thrilled when Rails was announced because it gave me an opportunity to actually use it for real projects instead of shell scripts. And I've been through various ups and downs of best practices just even in that space. When you're younger and you're very ambitious and you're very proud of the work that you're doing, you're like, valuing the terseness like, "Ah, here's a one-liner, here's a meta programmed this Sunday kind of ... I wrote software that built my software." Then you ended up having to fix the bugs that are inevitably triggered by that and realizing now you have to be smarter than the guy that you were last week to be able to figure out what it is that you missed when you were there. And then I had a kid and then it really felt like I lost 20% off the top there is I wasn't sleeping well and I had so many other things going on in my mind and I realized and I'm getting older, my brain is literally not working as fast as it used to as it used to.
(17:55):
And all of those kinds of pushes on it made me realize that being clever just has no value and frequently negative value. And a thing that we frequently say to ourselves in our team is like, imagine a very stupid person is looking at this code because that's probably going to be you. And can a very stupid person understand this? And if the answer is no, then let's pull it back a little bit. Or what idiot wrote this, get blame that idiot was me two years ago.
Chris Vannoy (18:28):
Oh yeah. There's always like multiple reasons for like multiple costs for code in a way. There's the actual literal cost, like performance costs, like this branch of code will take a little bit longer, like something like that. But there's also that sort of cognitive cost, right where you have to explain it or you have to have an AI model choke on it later on to put it in today's terms, right? You're not having to explain it quite so much sometimes, but instead you throw some AI model and it's like, "I've never seen anything like this in my training model. I don't know what this is. I'm going to make some stupid guess."
Patrick Byrne (19:04):
Or a junior engineer doing the exact same thing.
Chris Vannoy (19:07):
Yeah, the exact same thing. It's kind of funny how the most stock, speaking specifically of like Rails apps, like the most stock boring buy the boilerplate Rails app I've experimented around with AI tools in those and they just fly. It's fantastic, right? As long as you follow, this was always true. I remember saying this in Rails apps again 15 years ago, "Just follow the conventions. Don't do anything weird. You'll be fine." And it turns out that was the right choice all along. Who knew?
Patrick Byrne (19:38):
All along turns out that, oh, you just put the code where it belongs and you call the methods as they should be and a lot of it becomes much easier.
Chris Vannoy (19:48):
Yeah. Do all the boring stuff everybody else expects and it'll be fine.
Patrick Byrne (19:52):
Do you feel the thrill of discovery? Maybe not. No. Is that okay? I would say it probably is.
Chris Vannoy (19:58):
The trick is you got to find that in other parts of your life, which kids help, but
Patrick Byrne (20:04):
That is a never ending adventure that is for sure.
Chris Vannoy (20:07):
Yeah, lots of discovery.
Patrick Byrne (20:08):
I want my day to be boring. I want my data to be so boring because it's all I have the energy for sometimes.
Chris Vannoy (20:13):
The other thing I'm curious about, you kind of mentioned at the top, you're still in code all the time. I've always found that difficult, the sort of the balance of I'm in code all day and I'm managing people. How do you manage to balance that? I'm honestly
Patrick Byrne (20:27):
Looking
Chris Vannoy (20:27):
For tips.
Patrick Byrne (20:29):
I manage it probably better than before, but certainly when I was a baby manager and trying to do everything and was also still, my code output was my definition of success and trying to both it. I did both poorly. I did both absolutely terribly. I should have focused on becoming a better manager, but I haven't had to of late because, like I mentioned, the kind of varies the ups and the downs, the growing and the shrinking. We ended up kind of selecting for a team that, like I mentioned earlier, it's kind of a big responsibility, but it's also a pretty big opportunity to wear a lot of hats and have a really huge impact both inside the organization because it's a small team, but also on the world at large, because Triple is top a thousand site, but we've selected for people who wanted that, who gave a crap and who at this point kind of don't really need managing.
(21:25):
I'm frequently spending a little bit of time of one-on-ones kind of apologizing like, "Yeah, I haven't really been paying too much attention to what it is that you're doing. Let's talk about it. What do you need?" And they're like, "I don't really need anything because if I had a question, I already asked it. " If I needed help with something, I already reached out to me or to other members of the team that I had a need and I solved it. And sometimes I'm part of that solution, but a lot of times I'm not and I'm having to remind myself that's also what successful leadership looks like. But I ru the day where I have to start actively managing my team or there's some performance management or something that needs to come in because I worry that I'm a little rusty there because I really do get to spend most of my time.
(22:09):
Our CEO calls at the pat lane of just knucklehead distracty stuff that kind of needs to happen or it needs to be explored, but the team is humming, the team is focused and that focus is incredibly important and we could throw a bunch of stuff on their plates, but then they're going to slow down or they're going to get distracted or they're going to be thinking about three things at once when I really need them to focus on the one thing and then tomorrow think about the second one. So I'll just kind of put that on my plate and go heads down for maybe a couple of days and come up with like, here's 80% of a solution and I need the team to now participate in making it real or like, here's an exploration. This is worth pursuing. Let's put it on the roadmap.
(22:52):
This is an exploration. This is not worth our time. Let's not.
Chris Vannoy (22:56):
Yeah. That's sort of proof of concept work, this may not turn out to be a thing at all, but I'll hack something together and we'll see if it actually does anything. And then we turn it into a real boy at some point.
Patrick Byrne (23:09):
Exactly right.
(23:12):
A couple years ago, our search vendor got bought by another company and thankfully with a bit of a grace period be like, "We will not be renewing your contract," which meant we needed to find a new tool for doing our searches. And we thankfully had already been kind of on the fence of like, "Do we fire these people and use a new tool?" So we were kind of a little bit bootstrapped already on that front, but that was like boom. That's what I did for about six weeks was we had to win a hard deadline and it's like you just need to like, let's do that. And then we kept the team focused on the three months of roadmap that we had defined for a big product launch that we were expecting by the end of that year. And so I was able to really take that on and say, "If anybody needs anything holler, but otherwise this is what I'm doing." And it worked very smoothly and I feel incredibly fortunate.
(24:02):
I feel like I can probably take some credit, but most of the credit goes to the culture that we've built and the team that we've fostered.
Chris Vannoy (24:09):
You mentioned kind of selecting for that sense of ownership and when I would phrase it, I would phrase it as like, has an apropriate sense of shame, right? Or the other way to say it is like they care, right? I used to say like, "As long as they care, I can make everything else work." How do you select for that? Well, actually, let me back up. Do you even hire all that often anymore or is your team remarkably stable?
Patrick Byrne (24:34):
We haven't hired anyone for about 18 months now and we got real lucky and managed to, when we were hiring, we were looking for a front end engineer and a backend engineer and there have been times where the search has been months and in this case, I think we found them all within a couple of weeks. And it's funny, they're both named Marcelo and they both started on the same day. So there's a lot of contention about, well, depending on who's having a better kind of run of things, like who's real Marcelo and who's backup Marcelo, which is a fun thing to bandy around. But the hiring process is, it's also gone through various levels of rigor and various levels of process, but right now what it mostly is, is me and one of the engineers on the team that we're hiring for and it's about an hour to 90 minutes after they've gone through a screening call with our HR.
(25:26):
I would love to be able to send people home projects and come back and show me, spend a couple hours and fix this bug on this thing. That had always ended up being just like a real selector for like people don't have time or like your test is either too contrived, it's either too simple or it's too hard. And what really turns into is we've really kind of honed it down to we've got a mock up of the Dribbble.com homepage and we're like, let's imagine that the code got nuked and we're starting from scratch, there's no prior art. Walk me through how you would architect this And we do it very much like we do our own kind of internal conversations is that we're here to collaborate with you. We're going to ask probing questions the same way we would ask those probing questions if we were doing this when you were on the team.
(26:15):
We'd be like, "Well, what about this and what about this? " And kind of refining that scope and that's about like the first half of the conversation and I've found that you can usually get within about 10 minutes, do they know what they're talking about or do they not? And I don't care honestly what the answers are. We don't even have to say it has to be a Rails app even though we are and we're hiring people who can contribute in a Rails app. And for front end engineers, we're hired for people who would feel comfortable learning a litle bit of Ruby enough to kind of start working in ERB and stuff and be able to run a Rails app on your machine and kind of troubleshoot as needed. But it doesn't have to be that or they don't have to be using the front end tools that we're using.
(26:58):
I don't care what the answer is. I care that you can articulate what the answer is. I care that it's clear that you've got a vision in your head of where you want to take it and that when I ask those probing questions where the other engineer asks those probing questions that you're able to be like, "That's a good point." Either defend, I hear what you're saying, but X, Y, Z, it's already handled, or we can handle that later, or we can easily incorporate that in or taking like, "Oh, that's a good point. I hadn't considered that. Well, here's what we could do differently and just roll with it. I prefer people who've come from smaller teams before because there's nowhere to hide. If you're coming from an Amazon, you're touching one small slice of a thing." You
Chris Vannoy (27:43):
Also had a lot more support structures in that sort. You
Patrick Byrne (27:45):
Have a lot more support structure and it's definitely not a better or worse when we have had to let people go, it's frequently not because they're like bad engineers, it's because there is somewhere else that they're going to be successful and they're not going to be successful here with the kind of loosey goosiness of it or the kind of bootstrappy parts of some of things. And some people are really interested in doing that. Some people want to check in in the morning, have a list of checkboxes to check and then leave at the end of the day and that's fine. I do not want to tell anybody that that's not a reasonable way to live. If you're waiting to be told what to do, this is maybe not the team for you. And then the second half of the conversation really just revolves around, let's talk about what you've done, what are you proud of?
(28:32):
One of my favorite questions, especially when I'm hiring for a senior engineer or a hire is, tell me about a time you took down production, which can sometimes feel like a gotcha so I will frequently, if there's any kind of hesitation on their part, I will list the last time we brought down production, like here's what we did. And then I ask them, "What did you learn?" Because that's what I care about. If you've never brought down production and you're calling yourself a senior engineer, I genuinely question whether you're a senior engineer, how hard are you trying? And how do you learn from your mistakes? What do you take away? And if they take away, "Oh, everybody's against me. If they take away, it was my boss's fault. If they take away QA really dropped the ball, I'm less interested in continuing the conversation with people.
(29:16):
" But if their takeaway was, it turned out that we were testing the wrong things. And so we changed our CI process. It turned out that we had built this too complex so we simplified it or something like that. Again, I don't really care about this specific because I care about their ability to think about the problem and kind of rotate it in their head a little bit and see, "Oh, here's what we missed. We're not going to make that mistake again. I'm going to make a different mistake tomorrow."
Chris Vannoy (29:41):
Yeah. And you will make mistakes. A similar technique I used, and feel free to steal this, is I would have folks bring their own code to an interview and then just we'd get around and that same sort of probing questions, throw their code up on the screen. I don't care what it is, whatever esoteric language you want it to be in, whatever you're happy with, Whatever you want to show off. I would actually tell people, bring me the code you hate that you've written. No one ever took me up on that, but I swear to God, if anybody ever did, they would've gotten hired on the spot. That's
Patrick Byrne (30:11):
The best. That's the best.
(30:14):
Similarly, I love asking people what's your favorite thing? For backend engineer, what's your favorite thing about Ruby? What's your least favorite thing about Ruby? And the people who have an answer for what's their least favorite thing about Ruby are by far tend to be much stronger engineers. People are like, "Oh, I love it. " Again, are you really trying? If you can't list six things that you don't like about your favorite thing, then how much are you paying attention? It's not about complaining, but it's about having an opinion and it's about having a sense of what is good. And we don't even have to agree. It's actually important that we don't always agree on what we think is good because that's where the work is.
Chris Vannoy (30:58):
Yeah. Lots of times. So what are you excited about going forward? Where does Dribbble or your own work go from here?
Patrick Byrne (31:06):
Oh, that's a very good question. For those who were paying attention, Dribbble, this is not new information, but over the last few years, we really pivoted from being a social network first to being ... Our main focus is being how can we help our members make a living doing that? And so that's where we introduced the marketplace into the Dribbble App itself and that came with some kind of shifts in priorities and so on. And we took about a year building that kind of the MVP and we've spent maybe then of the last year really refining that. But where we're really focused on right now is how do we continue to widen that funnel? How do we bring more leads to the designers who are looking for work? How do we bring more high quality leads? As we've learned is very much the balancing act.
(31:58):
We can turn the dial for quantity. We can turn the dial for quantity. No one's happy if the dials on either extreme, but we want to make sure that people find value in logging into Dribbble.com every day and looking at the project board or looking at their inbox and seeing that the people that have reached out like, "I like this logo you did. Can you do a logo for me? " And facilitating that as well as the larger agencies who are finding work on the site and actually just having strategy sessions just this week of the exec team of what's the rest of the year hold and it's really all about how do we continue to refine that funnel.
Chris Vannoy (32:35):
I spent a chunk of my career building MarTech products where marketing technology stuff where it's like I ended up building a lot of what you're describing as sort of like a marketplace situation where you have inventory and then you have to get a buyer for that inventory. And how do you build something that can work for both ends of this market? How
Patrick Byrne (32:54):
Do you both it? Honestly, 90% of the questions though that we ask about anything is it's not an either or it's we really do need to both ... We need to continue bringing in strong designers and demonstrating to them why it's worth participating in the community while we're also bringing in high intent qualified buyers who are looking for work and really kind of distinguishing ourselves from maybe the fivers of the world. It's from moment one when we really locked in on the marketplace strategies. We're not looking for a race to the bottom. What we're looking for doing is, and that's really why we articulate it as we want people to be able to make a living doing this. It's not just about cranking out $5 logos. It's about really, can we help you foster relationship with these clients and continue to ... The clients benefit, you benefit.
(33:41):
And if you both are benefiting, then we're benefiting too. And that keeps paying for the servers, that then keeps expanding, which then keeps everything going. Everyone's incentives are aligned and that makes me feel much more comfortable than say other organizations that operate in similar spaces that I would be less excited to participate in. That kind of virtuous cycle is what keeps it going. And speaking purely on the engineering side, because the users don't care about our tech debt, we very much do is over the ... Keep mentioning the ebbs and flows and highs and lows over the last 13 years is sometimes it's, no, we just got to get to the end of the week kind of stuff and we'll deal with the technical debt later, but like right now we have a feature that needs to ship because it's going to pay for everything.
(34:36):
And over the last couple of years, we not only pivoted the app, but we've also just paid down just tremendous refer to it as platform health work as the euphemism that- Oh, that's good
Chris Vannoy (34:49):
Framing. I like that.
Patrick Byrne (34:50):
I might steal
Chris Vannoy (34:51):
That. That's good.
Patrick Byrne (34:52):
It's not really paying down debt even though maybe we are, but that also encompasses bug fixes and things like that. But we just rolled out a rail 7.2 upgrade because every time we're close to caught up, there's another few releases, but it was just had some conversations with some of the other engineers and kind of laying out in that context of what are we doing for the next three months or the next six months is also like, what are we doing? What's the not chip away work?What's the stuff that we're actually going to need to put on the roadmap because I'm going to need my principal back and engineer working on, I need them for like a month on this and really defining what that is. And so we're looking at containerizing.
(35:46):
We're running on long running EC2 instances that we're managing with SALT and that's a system that's working really well for us. And it was kind of an easy stop off when OpsWorks was scaled down. That's what we had been using to manage our infrastructure with Chef. And this is more of a sidestep, but every time we have a DDoS outage, one of the bullet points on the takeaways there is if we were running, if the XYZ changes to our infrastructure, this wouldn't have been a DDoS. We almost certainly would have been able to absorb it before the WAF kicked in. And so I think we're finally, we've kicked down enough of the large boulders and the existential, we have to get to a new enough version of Ruby. We have to get to a new enough version of Rails. We have to get off this library that hasn't had an update in five years kind of thing that we're asking ourselves, wait a second, is this next?
(36:48):
And now we're having to turn into the really define the hard work of defining what the North Star is. This is what we want to build toward. And so we can ask, then we can like, well, what's the order of operations moving from unicorn to Puma? Do we do that before or do we do that after? It'll be easier after, but if we do it, because then it's just changing the task definition, but then there's all these problems we would have to solve for serving unicorn behind engine X in a container that we don't want to deal with maybe. And then we've had this conversation various engineers many times over the last year as we're kind of like feeling it getting on the horizon and we always end up with like, well, it's all trade offs. And it's like, these are the 18 different paths we can take.
(37:30):
And now we're getting to the part where we actually have to make a decision and that involves really getting it on paper, like what is the goal? What is the outcome that we want?
Chris Vannoy (37:42):
We'll start with that. And then when you work backwards, everything starts to get clearer when it's like, we know this is where we're going to be in this much time. Exactly. And then you just work backwards to, what do we have to do to actually make that happen? And
Patrick Byrne (37:54):
I don't know that we even need much more specificity than containers, but that's all that we've had so far is like, no, we need to get there because we have a little more of that on ECS and we love it. It's working perfectly. Deploys are just one button and we want the main app to get there now too. And so if we're building a new app, it would be easy because you got to like dev containers, you get all that stuff out of the box, but this is a mature app. We're looking at some libraries that are tough to install that we're like, do we need these? Can we change the app to not need WKHTML to PDF anymore because that's a dead project now. It's fine. It worked. It will continue to work for long time.
Chris Vannoy (38:37):
Yeah. I've had difficulty installing that myself with a couple of long, what I like to call well loved Ruby applications. It's
Patrick Byrne (38:45):
A beautiful stuff.
Chris Vannoy (38:46):
You start to know a handful of gems that when they're in the gym file, you're like, "Oh, I'm going to have a long day."
Patrick Byrne (38:51):
Oh, we're going to have a fun one. We still have one thing that is using paperclip. I'm very embarrassed to admit that.
Chris Vannoy (38:57):
Oh no, it's fine.
Patrick Byrne (38:59):
All stuff that's written in a while has been using Shrine, but our avatars are still using paperclip and we're like, "That's just going to stop working." One of these days.
Chris Vannoy (39:10):
We can end this by making you feel a little bit better. So I had a client last year, had one of these well loved Rails apps. They were still running Factory Girl. So not factory bought Factory Girl. Yeah, see?
Patrick Byrne (39:27):
Cool. I was about to get all up and arms like, "So are we? " And then they're like, "No, we're running factory blah." We've made that transition. That was
Chris Vannoy (39:33):
Close. All right, Patrick, thank you so much for taking some time out of your day today.
Patrick Byrne (39:38):
I
Chris Vannoy (39:38):
Really appreciate it. If we wanted to follow along, where could we do that?
Patrick Byrne (39:42):
I'm moderately active on Bluesky. It is not worth following me there, but come to Dribbble.com. If you or anyone you know cares about graphic design or is just ... I come in as a fan just as ... Part of why I joined the company is I'm a fan of graphic design. I'm a fan of design generally. I have no aptitude whatsoever, but I can make servers work and that's the way I was able to contribute. So even if you don't yourself aren't as a designer, I encourage you to come to Google.com. Just look at the cool shit that people are doing. I'm a big fan of our community. I'm big fan of the work that they're doing and that's what inspires me every day to do the hard work that is maintaining an app and encourage everyone to do the same. And if you know a designer, send them our way too.
(40:22):
And if we can help them make a living at it, then everybody's days
Chris Vannoy (40:27):
Better. Yeah. And I think not most importantly, but also importantly, if you're looking to hire a designer, come to Dribbble.
Patrick Byrne (40:33):
I've got lots
Chris Vannoy (40:34):
Of them.
Patrick Byrne (40:36):
There's many of them eager for work and some of the best designers in the world are active there and you want to hire them.
Chris Vannoy (40:42):
All right, awesome. Thanks so much.
Patrick Byrne (40:45):
Awesome. Take these man.
Chris Vannoy (40:46):
All right. See you. Bye. That was Patrick Byrne, Vice President of Engineering at Dribbble. Three things that struck me from that conversation. One, process you added to solve last year's pain often becomes this year's pain. Whatever's closest to production deserves your team's highest priority. And if you've never brought down production, you might want to ask yourself how hard you're really trying. If this was useful, follow the hallway track wherever you're listening so that when the next one shows up, it'll already be there for you. I also write a weekly newsletter called Expedite over at getaxiomatic.com. Well, I shoot for weekly. It isn't always weekly. It's more of this kind of thinking but on a slightly irregular publishing cadence and go check out Dribbble, three Bs so the best designers in the world hang out there. Thanks, Patrick. See you next time and see you next time I'm in Minneapolis.