Conformity vs Autonomy

About this Episode

The panelists explore the tension between conformity and autonomy within software development teams and the balance of standardization and flexibility in coding practices. The conversation revolves around their efforts at Acima to standardize pull request assignments and the dual roles in code reviews, highlighting their team's unique approach of using a chatbot compared with other teams using GitHub Actions. They also discuss the challenges of integrating new developers into standardized practices, especially for teams with a lot of junior developers.

Eddy emphasizes the importance of standardization across teams to reduce the onboarding time and confusion when developers shift between projects or teams and advocates for company-wide code standardization to facilitate easier transitions and maintain consistency. Dave discusses the implications of standardizing tools versus processes and how each choice affects team operations and risk management strategies.

The discussion turns philosophical, pondering the broader impacts of autonomy in development practices. Dave and Tad debate whether autonomy should extend to individual tool preferences or be constrained by team and organizational standards to ensure cohesive and efficient operations.

Transcript:

TAD: Hello. Welcome to another episode of the Acima Development Podcast. My name is Tad, and I'm the one who's going to be hosting today. Today we're going to be talking about conformity versus autonomy, or another way to put it is, how much do you need your devs to standardize versus how much flexibility are you going to allow them to have? Today I have with me, Eddy.

EDDY: Hey, guys.

TAD: And Ramses.

RAMSES: Hey, guys.

TAD: Sergio.

SERGIO: Hey.

TAD: Dave.

DAVE: Howdy, howdy.

TAD: One of the reasons why this is kind of timely for us is because we have several different services, several different teams here at Acima, and we've been making a push to standardize things between the teams and to become a bit more uniform between the teams. So, I have some examples, but I thought I'd throw that out. What are your thoughts? What are some of the things that we're trying to standardize on right now, and how do you feel about it? Or maybe I'll just go first.

So, one thing that we're trying to do is standardize how we do assignments of pull requests. And the team that most of us are on, actually all of us on this podcast today are on, we have two different roles that we have when we're doing code reviews, where one of them is a code reviewer, and that person just reads through the code, looks for anything weird or unusual, maybe asks some questions, and then they give the thumbs up: yes or no.

The 2nd role is a full reviewer, and that person goes through, reads all the code, but then they also go through a bunch of steps to actually exercise the code and assure themselves that that code is working. And that works great for us because then we have two people who are reading the code and two people who are then QA-ing the code because we also have a third QA person. But the other teams don't do it that way.

What we've done is we actually wrote a chatbot that would manage our assignments for us so that we get a mix of people doing the reviews. And not everyone gets back-to-back full reviews because, you know, you can skim through code, maybe on a PR, and that takes you 5 or 6 minutes. But it might take you 30 minutes to actually go through and exercise all that code. And so, because full reviews are a little more time-consuming, we like to make that a little more fair.

And having our chatbot and having coded up a way for us to do our code reviews works great for our particular team. But our team is the only team that does it that way. So, the other teams are all doing GitHub Actions. So, we're trying to reconcile the fact that we have a chatbot, and the other teams have GitHub Actions. I think chatbot is better, but we're outvoted in this. It's not quite a democracy. So, we're currently trying to figure out how to get GitHub Actions to work for our needs.

EDDY: I think that standardization for code reviews and testing, et cetera, is super crucial, right? Because what happens if you pick up...and I don't know if it's common practice in other companies to allow a developer to just clone the repo that the other team works on, and then just do the code change, and then just assign it [inaudible 03:35]. I don't know how common that is. But I do like the idea that Acima facilitates that. And having a standardization, I think, is important company-wide, right? So that you're not daunted with different team dynamics.

DAVE: I think there's a thing to look at here as well that the way our team works and the other teams work we're talking about standardization of, like, generic process, right? It's like there's this implicit mapping from, like, GitHub teams to their team that isn't present on ours. So, it's a struggle for us because we do things a little bit differently. And we sometimes wonder, okay, do we want to standardize on a tool, or do we want to standardize on process? And, in this case, the processes map to tools that are different, right? That don't cooperate with each other. Yeah, it's a sticky issue. Like, either one of the tools has to be upgraded so that it can do both, or one team has to change process.

EDDY: I think it's important to also distinct this, you know, that the Atlas team mostly comprises of junior developers, I do want to say, like, a good chunk of that, maybe half of the pie. Maybe that's deviated since, but historically speaking, the team that we are representing for most of us today are from the Atlas team, which is the name, right? And we adopted the idea of a full review and code review in a way to sort of make sure, you know, that the code changes are solid. And if you have a junior developer pushing out code, I would argue that the probability of a bug, you know, being released is greater since they haven't had the full exposure as a senior developer.

So, the reason why our team deviates a little bit more than others is because of how many developers, one, we have and, two, how many of those are actually junior developers. So, I think that is an important distinguishing factor to give context on why we have different procedures.

DAVE: Yeah. It's a weird thing to draw it back to, but in my mind, it all comes down to how risk-averse or how you mitigate risk on your team. I've worked in shops where everything had to be reviewed, double-checked, super QA'd, jots and tittles because there's finance in this code, like, SOC 2 compliance, where whoever wrote the code cannot deploy the code. And I've also worked at a company where we had, you know, PHI and really sensitive data. But we had the agile mentality of if you want to make a feature happen, you own it. And if that means going into another team's project and into their repo across the building, that's fine because they're doing it to us.

And the mentality at the company was if you need to change something, you go to that team and say, "Hey, I need to add this feature." And, usually, somebody on that team will say, "I can help you with that. I own that piece, and I'll be happy to walk you through it." But then they walk you through it, and then in that code, you did your own deploys. Like, you walk it all the way to production. And the risk mitigation there was if something goes wrong, you own it. Nobody else can handle this for you.

There are other places, like when you've got a team full of junior developers, where you can't own this. If this blows up, you're going to need, for lack of a better word, an adult to come help you. You're going to need a responsible adult, to put it that way. That way, we can exclude me from that group. You need a responsible adult to come, you know, fix the server for you because you took it down. And this happens anywhere you have people that have, like, principle of least access, where developers can't manage stuff, or SOC 2 where you can't do the deploy. And so, all the processes kind of vary.

Tad, you mentioned at the top that we were talking about, like, when do we allow autonomy, and when do we want conformity? And, in my mind, I think it comes to...and this is, again, more risk mitigation, but it comes down to how much of your autonomy is going to affect the people around you, right? It's like your autonomy stops at my IDE, that your feelings stop at my rights, or your rights stop at my nose, or something like that. And so, we'll see people that it's like, if you want to develop on Emacs, or Vim, or RubyMine, it doesn't matter. If you want to ship this straight to production without QA, that matters. That's a process that, you know, that there will be people at your door saying, "This is unacceptable risk."

EDDY: Well, it also depends on how robust your QA integration really is and how big of a change that really...or the impact of that change really is, right? Like, for example, I'd argue that if you're pushing out, like, a simple text change, does that really warrant a QA assignment? Probably not. They can probably allot...their allotment for them would be better elsewhere, right?

TAD: I was going to ask, I think another part of it is can you pull a developer off one service and put them on another? Because if other developers have been pulled off of our team and need to do a PR against our codebase and they don't know how to do it, right? Because it's not the same process to do a PR on their team, like, we have certain standards. Like, it's small, and we have a full reviewer, and a code reviewer, and a QA person. And those aren't the same standards on another team.

And so, you know, it's like Eli Whitney in the interchangeable parts, like, can you move devs between different pieces of your codebase? Or can you move devs between other teams? And if you don't have some standard there, then there's friction. There's an impedance, right?

DAVE: Yeah, that's fair. The shop that I was at where we had...you would...in fact, we literally had developer hostage exchanges where you would literally go work on another team for, like, two weeks, you know, for a sprint and then come back, and they would send somebody in your place.

But, like, if you went to, you know, this other team and said, "Hey, I need to add this feature," you would have somebody that would be your Sherpa and would be your subject matter expert and say, "Okay. Let me show you the part of the project you're going to be working on. Let me show you what specs are covering that code. It's going to come in here. Data's going to go here, here, here, and here. You're following that? Okay, cool. When you hit here, you're going to have to...that's your feature. You have to change that. Change this. Don't touch that. Anything else is fair game. Go nuts."

And then, you'd go off and write it and come back and [inaudible 09:28]. So, basically, you would get that basic grasp of, like, the lay of the land. At that particular shop, we would not just throw you cold into 100,000 lines of code and say, "Good luck. Have fun." That's not fun.

EDDY: I actually want to advocate for company-wide standardization for code for that same reason, right? When you get dumped into another codebase. And I think at Acima, and Ramses, you can kind of correct me if I'm wrong here, but it seems as though each team adopts their own philosophy. It's always been that way from what it seems. And the code is a great example of that, right?

RAMSES: Yeah, totally different between different teams.

EDDY: To me, that's kind of difficult, right? Because I'm a junior developer who's going over a year, right? Just pushing out code changes and stuff. And it was a bit of a [laughs]...so the codebase that I currently work on it's kind of grown a soft spot for me because I know where everything is, you know, like if I need to add a new client, I know where that is. Cool. If I need to do this, oh, I know where the service object lives, whatever. And I can just reference it, and I can be very productive.

I did a change, like, two weeks ago, give or take, on another repository, another service, and it took me, like, God, I don't know, like, half the day to really understand, like, what they were doing before I could do anything. So, it's like, for me, it's like, I felt super, super, like, I was wasting a lot of time just trying to figure out, like, how that codebase works before I even went ahead and wrote anything or implemented any changes.

So, I can't help but wonder, if we standardize conventions for code company-wide, it will just be, like, a seamless transition to go and make another change, right? But at the same time, you run into the idea of, like, standardizing something that you are not a big fan of, right? And so, I guess it's kind of, like, a give and take.

DAVE: Yeah, wanting to have everybody work on the same standard that's a lovely idea. That and five kilos of cocaine will have you creating RuboCop.

SERGIO: But it has the bad side. It's like, if we standardize something, five years later, we figure out that this is not the right solution. It's like, this happened to us. We have this tool that we were kind of removing right now. I guess Tad is talking about that. I don't know if I can talk freely about that here, but it's like, we have this tool we built. I don't know who built in the team this tool. And we have a bunch of services using this tool, and we need to remove this, like, five years later. And it's like, whatever you make right now is going to be outdated in five years. So [laughs], standardizing is good, but sometimes it's [inaudible 12:09], you know, yeah.

DAVE: I think it's important to be careful not to set the standard for all time. We spend so much time as developers trying to tie the hands of future us, which is dumb because future us is always, maybe not smarter, but always more experienced, always older than us. And, honestly, legitimately, my biggest frustration as a developer is when I have tied my own hands. I'm like, I need to change the way this works.

I had a knockdown drag-out with a developer once over whether or not you could order the keys in a hash because a hash is a mathematical function, and the set of keys of a hash is a set. And sets, by mathematical definition, must not have an order. And I'm like, yeah, but the customer wants stuff to come out in the same order that they put it in. Customer gets what they want. Don't try to teach the customer set theory, right? It's tomatoes might be a fruit, but you don't put it in fruit salad. Don't do that.

EDDY: Yeah. Can't you organize a hash, though? I'm pretty sure you can, and it's --

DAVE: By default, Ruby and Python they keep a list, an ordered list as things get put in. Yeah, they have a hash for quick access, and then they have a list for ordering.

EDDY: So, it seems like a pretty trivial change, right?

DAVE: But ten years ago, you could just about have an honest-to-gosh fistfight with the math majors over whether or not you should be allowed to do that. If you can't guarantee something, there are programmers who will spend a lot of time locking things down so that they can guarantee that you can't, which is not the same thing as saying, "You can't guarantee." They want to guarantee that you can't. Now it's locked down. It's perfect. It's airtight. There's no way anybody can do anything wrong with the system. The problem is that every future change is something wrong with the system, right? It's something that hadn't been thought when that first mathematical formula was locked down.

TAD: I was just going to go back to ask Eddy some follow-up questions. So, first of all, when you say having the same conventions, is that RuboCop, or is that style guides, or is that training? Or like some of the people mentioned already, what if you hate those things that the other team does and you're glad you're not on that team?

EDDY: [laughs].

TAD: And you can do it your own way on your team. And maybe a related question that I'm going to throw out to the group is, is there some value to having competing ideas? If everything is genetically the same in your population, then that means some plague can come through and kill everything, right? And so, diversity does have some value where you have competing ideas, and the ones with merit kind of float to the top over time, and then they fall out of disfavor, and new ones kind of clobber those.

EDDY: Well, I think, okay, so it's more of a selfish ask for me than anything else, and I'll preface by saying that. Because, again, like, that was my first exposure contributing to another repository to such a degree, testing against a different codebase. And, again, like, the fact that I had to spend, like, half the day, you know, figuring out, like, their placement, you know, like where they locate a bunch of their code and stuff, and then how they write it; their style is a little different, too.

And so, selfish me would just be like, cool, if we can all just agree on, like, being explicit with our return nils [laughs], you know, like, and that's just adopted across the board, you know, you'll just look at it, and you're like, "Okay, yeah, cool, that makes sense." And I wouldn't have to stay there longer than I need to trying to figure something out, right? Or, like, using optional params, you know, like, in our team, we prefer it. We love it, you know. But other teams are like, eh.

Or, like, a really hot topic is, like, factories versus mocking, you know, it's sort of like...and so, for me, it's like, if we can standardize that, you just know what to expect when you go into the other team, you know. And you don't have to worry about, like, understanding their concepts, especially if you're just there to make a simple change. Like, if you're just there to do, like, a simple change that you need to work and they don't have the resources on their team to do it, you know, suddenly, your task is two times or three times longer than it would have taken the other person to do it, right? And it's just kind of hard to do that, you know, if everyone has their own lick.

TAD: I'm curious: are there some things that we maybe should standardize on and some things that are just trivial but we should standardize on? Meaning, we're always going to paint our bike sheds red, and that's just our standard color, right? So, for example, I know that we've had, in our codebase, like, four or five different HTTP libraries. And really, all the HTTP libraries do the same thing. They're a little bit different flavored, but they all make POSTs; they all make GETs. They all take a URL, right? Like, there's not a whole lot of difference.   And so, would something like that make sense to standardize across all the teams? Where it doesn't really matter, but we should pick something? Are there things like that that we should be considering?

EDDY: I've learned that if Rails can do it natively, use the Rails convention and don't try to get fancy [laughs].

DAVE: Basically, it's the same thing. It's like, bike sheds are red until further notice, or unless specified otherwise for a good reason, right? So, it's like, you can go to the water cooler and talk about how you should do it all day, what color do you want to paint it. That's fine. It's going to be red, unless there's a really good reason, and that's fine.

And for, like, HTTP, my out-of-pocket answer is, yeah, you should standardize because, you know, convention over configuration. Where we run into trouble is when we have convention and screw your configuration, which is kind of where Rails is kind of headed. It used to be, like, Rails 2, Rails 3, man, you could change anything. You could back that thing onto a wacky data store and just, da, da, da, all kind of...and everything was super configurable. And most of that's still there, but it's getting more and more complicated and more ceremonial to change those things.

The thing, specifically with HTTP, I love the HTTParty gem. It's the most simple, straightforward, like, httparty.getURL and response. And you're just done. There's no setting stuff up. There's no socket handling, da da da. Just do it and go. And most like Faraday and the other ones will, Excon, they'll let you do that, too, but it's a little wordier. But HTTParty had, at least as of, like, 2017, had a threading bug. I want to say it used green threads, which is Ruby's internal thread manager, which runs inside one system thread, so it doesn't thread well. You stack up ten threads, and it's exactly as fast as running one thing ten times in a row. There's just no speed-up whatsoever.

And so we switched to Faraday, which at the time did not have just Faraday GET. Like, Faraday 1.0 didn't have that. I could be wrong on that, but I didn't see it in the code. It was always Faraday dot connection do, and then inside the block, do your thing. It was ugly, but we needed it for performance. And so, that's an example of no, this bike shed has to be blue. It can't be red. It has to be blue.

EDDY: You know, I'm starting to think...as we've been talking, I'm trying to think of all the things that we can typically, like, standardize. And, like, some of that is enforced by RuboCop. Is it not? I mean, most of that should be enforced by RuboCop, assuming that your repository uses it, right? So, it really is just a matter of all adopting the same rules.

TAD: The same linter and the same rules for your linters.

DAVE: And to be clear, I love Rubocop. It's just I want to kill some of the cops that we favor as a team. I'm like, I hate that we made this choice.

EDDY: [laughs] I agree. You know, what's crazy is I used to be a huge fan of comments, right? And, like, anytime I wrote a function, you know, I found myself writing a comment about it, even though it was pretty self-explanatory. Until someone basically told me, like, "Your code should be explaining it to you, you know, from the moment you read it." Like, you shouldn't have to dig into the nitty gritty to be like, "Oh, that's what you're doing. You're doing something really fancy and stuff."

So, someone told me, and I can't remember who it was, and I kind of want to put them on the spot because, [laughs] like, that's rang true for me forever. It's pretty much what they said. It's like, if you find yourself making comments to a code, it probably means nine times out of 10 that it's more complicated than it should be, and you should consider refactoring. And that's rang to me true, you know, and for a while.

TAD: I've had an exact opposite experience where people tell me, "Oh, my code is so readable. It doesn't need documentation," and I beg to differ.

EDDY: [laughs]

TAD: I go in...and, like, "I don't need to document my code. It's self-documenting." And when I hear a phrase like that, I cringe.

DAVE: To steal a joke from [SP] Louis C.K., readability, readable, you know, writing readable code, it's like being called a jerk. If you say, "I'm not a jerk," you don't get to decide that. Other people get to decide that for you, right? So, if somebody comes to you and says, "Your code is really readable. I don't think it needs comments," then, yeah, especially if your comment is literally, do the thing, and then the line of code is very clearly do the thing.

It's especially from, like, the old C and C++ days, where you had to sneak up on your solution. You had to trick the compiler into giving you what you wanted as a side effect of the math that you were throwing at it. So, we had a piece of code go by this week where we have a certain number of products that can be in a list, and there was just one thing. There was only one kind of product. Well, now there's two things that can be in it.

And so, somebody stuffed in a bit of code that said, "Hey, if the list of products is longer than one, it has to be this combination." And I'm looking way down the road map, like, six months, nine months, ten months when we add a third product or a fourth product to this thing, and this is going to be wrong. Greater than one that's sneaking up on the side effect of, well, if you have two products, you've got more than one. Therefore, it's this comment.

And Sergio and I changed it so that it was like, "Hey, if you have this product and you have that product, then it's that combination of those two products." It's the same code. It does the same thing, but now I think it kind of doesn't need the comment on it, def combo item has item 1 and and has item 2. That's literally the code. I'm changing the names of the products to be a little vague here, but other than that, that's literally what the code is.

TAD: I should maybe clarify what I like in a comment. If you give me the mindset you were in when you wrote that code, the reason you made the decision, why you took the approach that you did, I love those type of comments. If it's, this adds A and B together and returns the total, then, to me, that's a useless comment because I can see what it does, but I rarely know why you chose to do it that way, what the trade-offs were, what your mindset was, things like that, when you wrote the code. And those types of comments are rare but invaluable.

DAVE: Yeah. Like, you have a thing that's like, A add B using this special adding method. So, you've got this, you know, conglomerate A and B, and the comment is, "Level four figuring compliance." And you're like, oh, that's why we have to use the custom thing to do it, right? And otherwise, it would be just this weird addition.

EDDY: You know, Ramses, you wrote something that's ringing true for me right now, and I kind of want you to elaborate on that, if you don't mind. Because I, too, agree with your sentiment, but I want to hear your opinion behind it.

RAMSES: Regarding the class-level comments?

EDDY: Yep.

RAMSES: Yeah. Well, there's just a lot of times, like, you'll see in a model, or a class, or whatever it's basically just a repeat of what the class name is, like, "Representation of user." Yeah, that's what your model is.

DAVE: It's just repetition at that point, and you're only putting it there because RuboCop demands the documentation. When I document a class, I try to say why. Why does this class have to exist, or what purpose does it serve? And you can...yeah, you can have...I can't think of an example off the top of my head, but you get the idea that the comment should not just be if you've got, you know, class particle accelerator and a comment that says, "A class for particle accelerator."

EDDY: Yes [laughs].

DAVE: It's completely useless, right? But if you've got a comment that basically says, "General class interface for all accelerometrox products," then you're like, oh, okay, now I know why we have a particle accelerator class.

TAD: So, going along with this, would you guys advocate for a standard commenting style? Because there's people that use YARD. There's people that use RDoC. There's people that say, "You must state your inputs, your outputs, and give a why for this class, or this method, or whatever you're commenting."

DAVE: I would say, "Yes," if it's high ceremony, if the interface needs to be...like, if it's a Conway's...[chuckles] Conway's wall, not Conway's Law, Conway's wall, that's like, another team is going to come use that piece of code. It should be documented like the old MSDN libraries where you could hit F1 anywhere in the code in Developer Studio and get, you know, a page of documentation and examples, and gazintas and gazotas, and every possible thing that this thing can do. Yeah, document the snot out of it. If it's a private method buried down deep in some sidebar class that only affects your specific domain in that module of that sub-piece of the code, I don't know, maybe not.

TAD: So, are you saying for things like our shared gems you would advocate for some kind of commenting standard?

DAVE: I feel like you might be baiting me into a trap here, but at the risk of sounding like a complete hypocrite, yes. What I will say about us hypocrites, [crosstalk 25:56] criticize hypocrites how you want, but we do have higher standards than you.

EDDY: So, you know, it kind of begs the question, right? So, like, standardization and comments, I feel like we don't have that, and I'm not very spoiled or privy to that, right? Because, again, I'm a junior developer, not much of experience in the industry. But I do love hitting, you know, certain logic, you know, and they basically say, "Hey. Make sure you keep this in mind when you make a change here or whatever," right? I love that.

I love that because they're being super, like, they're being super nice to me when they're saying, "Hey, dude, if you're going to make a change here, like, just make sure you're cognizant about this, this, and this, you know." And comments do that, and they do accomplish that. And so, I feel like we don't have a standard on that, but I feel like we should, right? I think it is nice.

TAD: So, I'm curious to ask about standardizing on some other aspects and how you feel about it. How would you feel about doing standardization of all of our setup stuff for all of our different services?

EDDY: Oh, that would be nice.

TAD: So, would you be okay with forcing everyone to use Docker or some other system?

RAMSES: Sure, why not? Make the process much easier.

EDDY: Okay, so I have a love-hate relationship with what you just said, right? Because there are people who utterly refuse to use Docker, right? Because their machine just isn't strong enough. So, like, why not provide an alternative for individuals who just don't have a beefed-up computer, for example? Or not everyone uses the same operating system. And what if your documentation is only catered to a certain OS? Then, at that point, you're kind of like, "Ugh," you know, so I don't think you can truly standardize --

TAD: Well, you can standardize hardware. You could say, "Everyone must have an Apple laptop."

EDDY: Wow. Yeah. I didn't realize that that was possible.

RAMSES: Yeah. Tell everyone to start using Electron products, in-line, editors only.

EDDY: [laughs]

TAD: Yeah, like, would you guys be okay with saying, "Everyone uses Linux"? Because that's something that pretty much everyone on our development team would be able to use and that has maybe the best Docker support.

EDDY: I haven't had an issue with Mac. Basically, anything that I needed to accomplish, like, Mac has been able to provide for me. So, like, there hasn't really been a need for me to be like, oh man, I really wish I was on a Linux [laughs] distro. There hasn't really been a necessity for that. I feel like that's because macOS has just gained so much credibility for development. Am I wrong on that assessment?

TAD: Well, we have a lot of contractors that have to bring their own laptop. And so, you have the luxury of getting a company-issued laptop. So, you're indirectly advocating that our contractors would go out and buy Apple products.

EDDY: It's a good point.

TAD: Standardization has trade-offs, right? It's like, it would be great if we all ran on the same hardware, but then everyone who doesn't have the standard has to go out and somehow now fit to the standard.

EDDY: I feel like it's easier to enforce standardization on code than anything else. Like, if you're standardizing something on, like, hardware, you know, I feel like that's super trivial, and you may lose potential talent because you're telling them, "Hey, you're forced to use this specific machine, this specific operating system." So, like, for example, I've paired with our contractors who were from India and some of them, yeah, and like you said, they use Linux. They use different IDEs. Like one of them uses Sublime for God knows what reason, you know.

TAD: Because it's fast and awesome.

EDDY: [laughs] And the thing is, is, like, you would see him just kind of, like, flow through that seamlessly because he understands that super well. And I'm just like, cool, we shouldn't be forcing you to be using something if your innate flow caters to a specific software, so...

TAD: But would it make it easier for you to pair with him if you had standard tools and standard hardware and maybe even, like, a standard IDE that you both were using?

EDDY: Well, I want to confess something on record...Ramses because he's on the call. When we first paired, when I was learning how to code, he would pair with Vim. And for most of the time, like, early on in our pairing, I was like, oh man, I was like, what are you doing? Where are you at? I don't even know what I'm looking at. So, there is a level to that complexity, but I feel like eventually, you kind of just grow accustomed to looking at someone else's IDE, and you just know what happens. You know, I feel like, as wisdom prevails, it's easier to adapt oneself.

TAD: What about you, Ramses? Side note, Ramses is a Vim user, and he loves Vim. So, I'd like to hear what his thoughts are.

RAMSES: It'd certainly be easier if everyone was using the same tool in terms of collaboration. If I want to do a live sharing with someone in Vim, it's technically possible. It's not great, you know. It's not a great experience. It's certainly not as seamless as, like, Live Share on VS Code or live coding on RubyMine or, you know, any other tool. If I'm planning on doing a pairing with someone, I'll just open up VS Code. It's easy enough. It doesn't impact my workflow that much.

EDDY: And to your credit, Ramses, I think you tried using it entirely for a month, right?

RAMSES: Yeah, I've used it, like, I mean, I've used a wide variety of IDEs and other editors. For the most part, I don't have a problem with VS Code. It works just fine, for the most part --

TAD: I think the trade-off here is individual productivity, right? If you let developers choose what they want, then they'll choose the most productive, most familiar environment that they have. But if you standardize, then you might be increasing, like, pairing productivity or some other form of efficiencies, right? Like, if our servers are on Linux, they're all running in Docker. And so, if everyone ran Linux and everyone ran Docker, it would make it a lot easier for our DevOps team. So, are you willing to choose the approach that makes our DevOps team sad, Eddy?

[laughter]

EDDY: I feel like there's not a right answer [laughs].

TAD: I'm kidding. No, it's just hard because there's trade-offs with all these things, right?

EDDY: Yeah, I think, to a degree, there has to be a balance between standardization and not. And I feel like I've been spoiled [chuckles] here at Acima because everyone gets to customize their machine, you know, to a certain degree. You know, it helps them with their flow. So, like, everyone can select whatever IDE they want to use. As long as they get the code out, it doesn't really matter. Or, like, some of us prefer to use different Git commands, you know, when rebasing or pushing stuff up. Like, that's fine.

Like, ultimately, it accomplishes the same thing at the end of the day. So, I like the fact that I'm not micromanaged that I have to choose certain hardware and, like, certain software. Because at the end of the day, the one who's pushing up the code changes is the developer, right?

TAD: I'm going to hit you guys with another one. How do you feel about standardizing on time? Meaning you do things at a certain time, and other people do things at a certain time.

EDDY: What do you mean?

TAD: Meaning, everyone starts their day at the same time. Everyone has their meetings at the same time. Everyone pairs at the same time. Everyone takes lunch at the same time. Everyone codes at the same time. Everyone does PRs at the same time. You could have a pretty regimented schedule and make sure that everyone's pairing at the same time, which means that you never have to coordinate with people to say, "What's your schedule? What's my schedule? Oh man, we're not going to be able to get together on this." Because it would always be free. Like, you could really standardize when certain things happen and how things work for your team.

EDDY: I don't really like that. And I'm just going off of my first reaction here. But I get hungry in different times than other people. So, like, what happens, like, if suddenly we're all forced to have lunch at 12:00 p.m.? But I'm like, "Oh, but I usually don't eat till, like, 2:00 p.m." Suddenly, it's just I'm not being productive because now I'm having to force myself to go against whatever my habits are.

Or, like, what if I'm like, I'm not very productive waking up at 7:00 in the morning and working at 8:00? What if I work better working from 9:00 p.m. or 9:00 a.m. to, like, 7:00 p.m., and that's the schedule that I prefer? And, like, as long as you get the work done, it really shouldn't matter, I feel like. And, like, time management should really be left off to the developer, in my opinion. Just, like, from the first reaction, I feel like the developer should be the one who pretty much decides the time management.

TAD: Okay. Ramses?

RAMSES: I think I am in the opposite camp, at least for the most part. I don't really care when other people start their day. If they want to start it later, end it later, it doesn't really faze me. But I think the parts of standardization that's good for time management is where...and this is something that we follow as an organization, where we have, like, a cadence, and we have structures like, okay, all teams do stand-ups in the morning, you know, between, like, 9:00 and 10:00, or whatever, you know.

And then, in the afternoon, okay, that's developer coding time, so no one else can schedule meetings during that time. Like, I mean, you could probably do pairings with other people during that time because that's when you should be productive, but it's not time for engineering-wide meetings or team meetings. Those are kind of blocked out at very specific times. I think that's helpful for team collaboration.

TAD: Yeah, I mean, I've kind of been playing devil's advocate or being a little bit provocative here, but the reason it did come to mind is because we did, a few months ago, agree on a team cadence where certain things would happen at certain times just because they found that they couldn't schedule things. They couldn't plan things because they never knew when people would be available or not. Or, on the other side of that is, you didn't know when you would have free time and when you'd get pulled into a spontaneous meeting, right?

EDDY: Right.

TAD: So, are there times that you think should be standardized, like meeting times, things like that?

EDDY: [inaudible 36:52]

TAD: Maybe not lunch. Maybe you don't dictate lunchtime.

EDDY: I want to go on record and say I don't really like meetings, personally.

TAD: [laughs]

EDDY: I have limited attention span.

RAMSES: I don't think anyone [inaudible 37:03] meetings.

EDDY: Dude, like, if I get put...and this is just me, like, if I get put in a meeting that's an hour long, after the 30 minutes, you know, I'm kind of wandering, doing something else just because it's kind of hard to focus [laughs]. So, maybe standardizing meetings so that it's short and concise sounds kind of nice.

TAD: How would you feel about something like meetings are standardized at 50 minutes long, and you always have to allow for a 10-minute break? You know, meetings always start on the hour or on the half-hour, and they are always, at most, 50 minutes long. And you always have to give a 10-minute gap before the next meeting.

EDDY: That sounds awesome.

TAD: Personally, I've been in back-to-back to back-to-back meetings where I've had five hours straight of meetings. And my brain is burned out by, like, hour three or hour four. So, would that kind of standardization be beneficial where you standardize the length and the style of the meeting, or maybe even the content of the meeting? Do you say, "If you're going to have a meeting, you have to have an itinerary for that meeting. You have to give everyone the bullet points of the meeting beforehand and say, 'This is only going to be 50 minutes'"?

EDDY: I would agree.

RAMSES: All meetings need to come prepared with a slide presentation.

EDDY: [laughs].

RAMSES: And it has to fit on three slides only.

EDDY: You know, I'm trying to think because, like, I've looked at other code, right? And I'm thinking, huh, the other things I've noticed that they have conventions on is, like, camel case versus snake case and, like, naming for your functions and methods and variables and stuff, you know. I think we can all agree that we share naming conventions for that. Some of the really silly ones are, like, oh, your characters can't...your line can't be longer than X amount of characters. That's where I'm sort of like, ah, you're forced to rewrite the code differently and probably run the risk of it looking worse because you're trying to fit [inaudible 39:13]

TAD: Well, arguably, if your line of code is 120 characters long, it's maybe a little too complicated. It could be broken into maybe a few lines of code.

EDDY: Yeah, maybe, maybe. Unlike silly conventions that, you know, that we have in our codebase, where I'm just like, oh, man, but it looks better with the unless [laughter].

TAD: Yeah. It is nice to read it all as one complete thought rather than three partial thoughts, right? I mean, there's kind of something going on sometimes in the code, where you want to break it into, like, it almost compares to, like, sentences and paragraphs. And you're like, ugh, like, I just want to express it in a certain way.

EDDY: Yeah, I agree. You know what's crazy? Is because sometimes those standardizations aren't present, I've learned to look at a code, and I'm like, oh man, this reads just like Ramses.

TAD: [laughs]

EDDY: And so, like, I'll go to the code. Like, I'll do a git blame. You know, I'm like, oh, it was Ramses. You know, I can just pick out, like, people's styles, right?

TAD: Do you think it would be better if you removed that fingerprint, where you can't quite tell the style?

EDDY: Yeah, right? So, like, if you're standardizing stuff, then it also removes, like, ambiguity because everyone's following suit, you know. And, to me, it's kind of fun to just kind of look at a code block and be like, oh yeah, this totally reads like Tad, you know [laughter]. And you're like, 9 times out of 10, you know, like, you're right.

TAD: I'm curious: how do you guys feel about standardizing on policies? For example, what if you had a policy, "No deployments on Fridays"?

EDDY: You know, a wise person once told me a little while back, and they said, "If you're afraid to deploy your code on a Friday, then your code is probably not ready to be deployed." Like, you got to be confident with your changes, and if deploying on a Friday raises eyebrows, then is it really ready for production? Probably not. I mean, would you both agree with that sentiment?

TAD: Well, I guess, just to clarify, so your argument is that perhaps standardizing policies is a symptom for a different problem.

EDDY: Maybe.

TAD: So, in your argument, the problem is we don't have confidence in our processes and our code quality, so, therefore, we make a policy to protect ourselves rather than fix the confidence problem or the quality problem.

EDDY: I feel like that's not what I said [laughs].

TAD: Okay. Well, then restate. I'm sorry if I'm misrepresenting you. Go ahead.

EDDY: [laughs] I was just saying, like, it's not the symptom of bad code or anything. It's just a matter of I feel like the reason why some certain teams prefer to not deploy on Fridays is because you do...regardless of how robust that code has been tested, you always do run a risk, you know, of it breaking something, like --

RAMSES: Yeah. No one wants to work on the weekends.

EDDY: Exactly. So, it's not necessarily because it's bad code. It's just you do run the risk of it breaking something, and if you do, you're making people work more time than they have to. So, it's more or less just being nice.

TAD: Are there other policies that you wish that we would implement that we don't have right now? We just barely talked about today in architecture meeting; for example, we floated the idea of...so, just for some context, we have a staging environment where we can deploy things, and kind of test things out, and try things in an environment that feels a lot like production but doesn't break things like production would, and it's a bit of a bottleneck. And so, now we're saying if you're going to take a lot of testing time, save that for the afternoon. And if you're just doing a quick check, do that in the morning because that alleviates a bit of a bottleneck that we've had.

EDDY: Yeah, I think that's a good problem to solve, right? How do you both feel about standardization on, like, how big a development team can be? If your development team comprises of over 20x, you know, developers, like, how do you standardize, you know, and keep all your ducks in a line, you know, when you have 20x people pushing [inaudible 43:34] on these, right?

TAD: Yeah.

RAMSES: Like, Amazon says, like, the team should only be the size that it takes to feed, like, two pizzas, so, like, four or five people generally.

EDDY: Really? That's their comparison [laughs]?

RAMSES: Yeah [laughs].

EDDY: Well, what happens —-

TAD: Yeah, they say if your team is too big to be fed by a pizza or two, then you need to split it.

EDDY: But what happens if I can eat a whole pizza? Does that mean that I don't need other people?

TAD: [laughs] They're theoretical pizza-eating people [laughter]. Yeah, it's a way to not necessarily have a fixed number but more just, like, a sense of, yeah, this team is too big, right? It's kind of more rule of thumb rather than saying exactly five. They're like, "Ooh, we're not going to be able to feed this team anymore." We are maybe too big. It is analogous, to some degree, to, you know, feeding a team, meaning providing work and coordinating that work with the other people, right?

EDDY: Yeah. And you sort of lose that as the development team grows, right?

RAMSES: Yeah. Yeah, it seems to be harder to collaborate and for decisions to be made on a larger team.

TAD: Yeah. And I think just because standardization is kind of the topic, the bigger the team, the more of these protocols, the more of these policies, the more of these standardizations, the more things that you need to make that team work.

EDDY: You know, I want to do a comparison, and I've never done the research on this. But, for example, if I were to look at, like, a Fortune 500 company, like, I don't know, like Tesla, Google, Amazon, et cetera, how they structure their development teams and how they standardize certain things, I think it'd be kind of cool to contrast. Like, off the top of your head, do both of you kind of have an idea of, like, how they differentiate themselves from startups?

TAD: I've never worked for a company that big, so I don't have any comparisons.

RAMSES: Yeah, same.

TAD: But I think Amazon still follows that rule of thumb that if you can't feed your team with a pizza, then time to split the team.

EDDY: But yeah, to kind of just come full circle, I do believe, you know, that there should be a balance, you know, on standardization, and there's an argument to be said for both.

TAD: Do you agree with that assertion that I just made that the bigger the team, the more standardization that you'll need to have in order to have that team work together?

EDDY: Well, the thing is, it's easier to enforce, right? So, if you have a standardization on code, then that just becomes an expectation, you know, regardless of if you're new, or you're a senior on the team, et cetera. So, being able to enforce certain conventions, you know, pretty much guarantees that that philosophy is being followed, you know, and it's easier to review and test.

TAD: Yeah. Well, I guess what I'm asking is, if I'm a team of one, how much standardization do I need? Do I need any?

RAMSES: Zero.

TAD: If I'm a team of two, how much do I need? If I'm in a team of 30 [laughs], do I need to add a lot to my linting rules if I'm on a team of 30 than if I'm on a team of 2? Or we can just say, like, "Oh, we kind of like it this way," and then we go with it?

EDDY: I feel like --

TAD: I'm kind of just throwing that out there because --

EDDY: I feel like Ramses has an awesome...you have an interesting opinion, right? Because for the listeners out there, Ramses is part of a smaller team than what me and Tad are in. And his team they finally have been able to claim their own service. And so, they've been able to sort of have a say on the way the structure of that service is written, you know, and architected. So, I feel like you may have some opinion on that, Ramses.

RAMSES: Yeah, I think the standard should be the same, regardless of the team size. It would be slightly more difficult to communicate the standard and probably to enforce it on a larger team. It's just when you have to communicate to, you know, 30 individuals instead of just 2 or 3, it's a little bit more difficult, but it should have the same standard, I would imagine.

TAD: The same standards because we're all part of the same company? Same standard just because that makes it easier for you to work with your, you know, coworkers? What's the reason behind that?

RAMSES: Probably for easier to work with your coworkers. And it could be the same company, but in our organization or in our department, we have different teams that work on different tech stacks, so creating that standard between, you know, Ruby and Java or whatever, it's a little bit different. But all the teams that are using the same stack, I mean, they should generally have the same standards.

TAD: Just because it reduces friction or communication overhead, or what's the...?

RAMSES: I'd say because it...yeah, it does reduce friction, and it increases cross-team collaboration. Like, if I wanted to move to a different team, if we had the same standard, it'd be really easy, or easier at least, if we were using the same stack.

EDDY: I agree, because it's like, cool, I'm used to using this certain gem to do a certain logic, and, suddenly, oh yeah, this service doesn't. They'll use a different gem. And you're like, oh, okay, cool, now I have to do some reading on their documentation [inaudible 49:09] how this works, right? Or, like, cool, we do our schema validation differently, you know.

And so, suddenly, now you're like, okay, now I have to read that documentation in order for me to come up to speed. And it's sort of like, if we can all agree on standardizing on what gems are being used, what libraries are being used, et cetera, it will make it loads easier to jump across teams.

TAD: What about everyone puts their documentation in the same place?

EDDY: That would be in an ideal world.

TAD: Because I know some teams put it in the docs directory, some people put it in the README, but some people put it in the Wiki, some people put it in Confluence, right?

EDDY: Right. So, yeah, in essence, I can agree on both [chuckles], on non-standardization and on standardization.

TAD: Okay. Well, I think we're at the end of time. So, final thoughts: how much standardization do you favor, and what areas do you think you favor standardization in?

EDDY: I think, as far as software is concerned, it should be pretty much free game.

TAD: Software like the tools that you're using?

EDDY: Yeah. For example, like, if you're trying to do some changes on, like, messaging for, like, Kafka, there's, like, a gazillion [laughs] software clients that do that. And you're like, okay, cool, we're all forced to use Lenses, or, like, Conduktor, or something. And you're just like, ah, but, like, I've never used it before. This sucks, you know? And, like, now you have to learn, like, a new...so, like, that just causes a little bit of friction.

So, like, I feel like I'm in the camp I'm like, cool, choose your own IDE. Yeah, choose your own Kafka consumer. Oh yeah, choose your own whatever, as long as you pretty much get the same result. At least that's my current opinion, and it could change tomorrow [laughs].

TAD: All opinions subject to change with new information and evidence. Ramses, what do you think? How much standardization do you like, and in what areas do you like standardization?

RAMSES: 100% conformity. Everyone uses Vim.

TAD: [laughs] Everyone standardizes to what your preferences are.

RAMSES: Or to Nano. I guess if I'm going to make everyone's life hell, I might as well make it as worse as possible.

TAD: Yeah, the least common denominator thing that everyone equally hates is what we'll choose.

EDDY: And if they don't like Vim, they're wrong.

RAMSES: No. Like Eddy said, there's a balance to standardization. I don't think it's necessarily an easy answer, depending on what you're trying to standardize. But I think, you know, at least having the conversation and trying to make a decision is probably the right thing.

EDDY: Agreed.

TAD: Yeah, I think after this discussion, and probably related to what Dave was saying earlier about convention versus configuration, is, I think I do like the hybrid where you have a recommended way, and you standardize around that recommended way, but you don't necessarily enforce the recommended way.

It's like we recommend Docker, but if you want to run Kafka natively, then knock yourself out, but you're not going to get the support. Or we recommend that you, you know, do X, and if you're not going to do X, then knock yourself out but realize that you're going to have a harder time with it. Cool. I think that's it.

EDDY: Thanks, everyone, for listening to us rant.