Kyle d'Oliveira

And a lot of times they're going to start getting education right away. And then we can do all of the usual things as well as as pull requests come in, we can review them and provide more education that way. And if we find constant patterns of every junior developer we come in makes the same mistake, let's codify that so that they get the feedback immediately.

And a lot of times they're going to start getting education right away. And then we can do all of the usual things as well as as pull requests come in, we can review them and provide more education that way. And if we find constant patterns of every junior developer we come in makes the same mistake, let's codify that so that they get the feedback immediately.

Yeah, absolutely. And I think there's even one step farther of a lot of linters can do auto-correcting. So if you care about having one line space between methods, don't even have RuboCop or a linter warn about that, just auto-fix it. That's something that a developer just doesn't need to worry about.

Yeah, absolutely. And I think there's even one step farther of a lot of linters can do auto-correcting. So if you care about having one line space between methods, don't even have RuboCop or a linter warn about that, just auto-fix it. That's something that a developer just doesn't need to worry about.

And it also removes a lot of this argument over should I use double quotes, should I use single quotes? If it just automatically fixes and developer can write whatever that they want, that's fine. But I've also run into issues of having pull requests being bombarded by style, and it really distracts from the code review about the behavior.

And it also removes a lot of this argument over should I use double quotes, should I use single quotes? If it just automatically fixes and developer can write whatever that they want, that's fine. But I've also run into issues of having pull requests being bombarded by style, and it really distracts from the code review about the behavior.

Yeah, definitely need to be careful there.

Yeah, definitely need to be careful there.

So actually, it's not clear where that point exists. I think it's probably going to be different for every organization and probably different for exactly the work that you're running into. I think the thing is to listen to the pain points of the developers. So if you notice that there are, you know, there's pieces of friction that occur between developers, like...

So actually, it's not clear where that point exists. I think it's probably going to be different for every organization and probably different for exactly the work that you're running into. I think the thing is to listen to the pain points of the developers. So if you notice that there are, you know, there's pieces of friction that occur between developers, like...

That's the point where maybe there's actually some tools that need to be built to make this easier. So one thing that I think comes up really quickly in organizations is often the concept of a testing server. So you've got your developer's environment, you've got maybe your CI, but maybe you want a production-like environment for things. And so you have a staging server.

That's the point where maybe there's actually some tools that need to be built to make this easier. So one thing that I think comes up really quickly in organizations is often the concept of a testing server. So you've got your developer's environment, you've got maybe your CI, but maybe you want a production-like environment for things. And so you have a staging server.

When there's five developers, it's really easy to just coordinate and be like, oh, staging is mine now. I'm going to test something. When it's done, I will hand it off and maybe reset it back to whatever the master branch and let people work that way. But that really falls apart when you have 100 developers.

When there's five developers, it's really easy to just coordinate and be like, oh, staging is mine now. I'm going to test something. When it's done, I will hand it off and maybe reset it back to whatever the master branch and let people work that way. But that really falls apart when you have 100 developers.

How do you coordinate one server where everyone is trying to test something if you have 100 developers fighting for that resource? You can kind of... fudge it a little bit by maybe having a fixed number and you round robin them out. But again, at some point, that's going to break down.

How do you coordinate one server where everyone is trying to test something if you have 100 developers fighting for that resource? You can kind of... fudge it a little bit by maybe having a fixed number and you round robin them out. But again, at some point, that's going to break down.

So if you think about what's the problem here is that every developer wants to potentially test something on an asynchronous schedule Maybe it actually makes sense to build some tooling so that you can spin up staging servers on Amazon EC2 or on Google on demand and just route them there.

So if you think about what's the problem here is that every developer wants to potentially test something on an asynchronous schedule Maybe it actually makes sense to build some tooling so that you can spin up staging servers on Amazon EC2 or on Google on demand and just route them there.

And so that's something that we ended up having to do really early of building our own tooling so that we can, we call them beta environments where we can have arbitrary number of them. Someone spent the effort to basically say like this branch on GitHub, I want a clone of the site.

And so that's something that we ended up having to do really early of building our own tooling so that we can, we call them beta environments where we can have arbitrary number of them. Someone spent the effort to basically say like this branch on GitHub, I want a clone of the site.